Issue35 – Dec2012 | Page - 1
Issue35 – Dec2012 | Page - 2
Issue35 – Dec2012 | Page - 3
Rotten to the core…A Roundup on Rootkits Rootkit is a common word in Computer Security. A word often spoken to describe a bad, vary bad type of malware. A rootkit is a program that can be installed and hidden on a computer without the knowledge of its user. It can be included in a larger software package, or installed by successfully exploit vulnerabilities or by convincing the victim to execute it by a phishing email.
Rootkit Evolution Rootkits became known to the world at the end of the last century. The purpose of the rootkit, at time, was to conceal additional programs that would allow an attacker to "sniff" or spy on the traffic to and from a computer. They earned the name ―rootkits‖ because they were mainly used on Unix derived computer systems where the top-level administrative account is called ―root‖. Thus to ―root‖ a system is to obtain top-level administrative privileges and hence obtain full control of the system.
Generally, books and magazines talk about rootkits, but do not go deep in the description them. The argument is quite complex and requires a dose of programming skills to be completely understood.
Later, however, this kind of tools has grown in sophistication, changing its targets.
Our intention is to approach the matter in a ―friendly way‖ in order to offer a vision of the whole picture even to a reader without programming knowledge… So keep your seatbelt fastened, we are flying to the rootkit land.
Today rootkits have improved immensely to the point that many of them are now much difficult to detect. Some are now "all-in-one" malware with a large number of features. Additionally, many current rootkits have the ability to capture sensitive information and
Windows users have become the primary targets, and the Rootkits have escalated the cybercriminal world.
Issue35 – Dec2012 | Page - 4
to help cybercriminals create and manage gigantic botnets. These botnets can then be used in a variety of ways, including spam forwarding and extortion. In the evolution, rootkits functionality, infection strategies and persistence mechanisms have changed greatly. However, the core purpose remains to assume full control of the machine by downloading additional malware. Rootkits, today, appear as very flexible malware. This flexibility is evident by looking at the features they have inherited by other classes of malware, such as Loggers, Trojans and Stealers. Traditionally rootkits were not necessarily malicious per se; they hid other illegal activities, but were limited in their deployment by the adoption of a multistage infection: first rootkit, then the Trojan or the Keylogger. Today, instead, attacker may be able to access information, monitor actions, modify programs, or inject other types of malware through the Rootkit. In some circumstances, rootkits today can be mistaken for Trojan Horses. Technically rootkits are not Trojans but their level of functionality is now equal (or better), and when an attacker has no special needs, rootkits can be used for the same purpose. The latest rootkits are now capable to subvert the memory of other applications running on the system, presenting the applications with a false view of the underlying system. This would effectively hide the rootkit from any antivirus scanning software.
To combat these threats, defenders have turned to the collection, analysis, and reverse engineering of malware as mechanisms to understand these programs, generate signatures, and facilitate cleanup of infected hosts. Unfortunately, malware developers are perfectly informed about how a malware analyst works, what kind of tools he uses and which techniques are normally applied to check the system looking for malware. During the times, malware writers have developed several techniques to divert and to avoid analysis of their ―creatures‖ by the good-guys. One of these techniques is the use of the socalled ―antis‖, a slang term to indicate a series of pieces of code used to detect and then evade the tools used by malware analysts, for example:
Anti-Sandbox Anti-virtualization Anti-antivirus
In the code snippet below (Snippet 1) we leave an example of an ―antis‖. For these reasons, the analysis, in presence of a rootkit, should be performed in cycles trying to avoid false patterns or false discriminatory elements.
Issue35 – Dec2012 | Page - 5
' antisandboxie / cwsandox / vmware by t0fx Private Declare Function GetWindowsDirectory Lib "kernel32" Alias "GetWindowsDirectoryA" (ByVallpBuffer As String, ByValnSize As Long) As Long Private Function WindowsDirectory() As String
'get windows path
Dim Buff As String * 255 WindowsDirectory = Left$(Buff, GetWindowsDirectory(Buff, Len(Buff) + 1)) End Function Private Function SystemDrive() As String 'get system drive letter SystemDrive = Left$(WindowsDirectory(), 1) End Function Private Sub Form_Load() If App.Path&App.EXEName& ".exe" = SystemDrive& ":\sample.exe" Then MsgBox "Caused exception at 0x44e85c", vbCritical, "CW sandbox" End Else End If If fuckingprocesses("SandboxieRpcSs.exe") = True Then MsgBox "Caused exception at 0x44e85c", vbCritical, "Sandboxie" End Else End If If fuckingprocesses("SandboxieDcomLaunch.exe") = True Then MsgBox "Caused exception at 0x44e85c", vbCritical, "Sandboxie" End Else End If If fuckingprocesses("VMwareTray.exe") = True Then MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware" End Else End If If fuckingprocesses("VMwareService.exe") = True Then MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware" End
Issue35 – Dec2012 | Page - 6
Else End If If fuckingprocesses("VMwareUser.exe") = True Then MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware" End Else End If End Sub Snippet 1 – Example of “antis”
Rootkits Internals The strength of rootkits is the ability to hide itself. In fact, it can become invisible to the user, application programs and the entire Operating System without losing its abilities. To understand the basics of rootkits we introduce the concept of ring of protection. This concept is the baseline of the constitution of the modern x86 processors, the family of processors used in current systems. The architecture of modern operating systems is based on these concepts. In x86 architecture, the protection rings (numbered 0–3) are simply privilege levels enforced by the CPU (and implemented by the OS) on executing code. Since all binary code, from operating system procedures to user applications, runs on the same processor(s), a mechanism exists to differentiate between system code and user code and restrict privileges accordingly.
Figure 1 - Rings
The OS executes at the highest privilege level, in Ring 0 (referred to as kernel mode or kernel land), whereas user programs and applications run in the lowest privilege level, Ring 3 (referred to as User Mode or Userland). Since both user-mode and kernel-mode programs must utilize system memory to run, the memory spaces of the two are logically separated, and every page in memory is marked with the appropriate access mode the processor must be running in to use that memory page. User-mode programs must spend part of their life in kernel mode to perform various operations, so special processor instructions such as
Issue35 – Dec2012 | Page - 7
SYSENTER are used to make the transition. The operating system traps the instruction when it is used by a user-mode program and performs basic validation on the parameters being provided to the called function before allowing it to proceed at the higherprivileged processor access mode. Kernel land is an extremely volatile environment where all executing code has equal privileges, access rights, and capabilities. Because memory address space is not separated, as implemented in processes in user mode, any program in kernel mode can access the memory, data, and stack of any other program (including that of the operating system itself). In fact, any component can register itself as a handler of any type of data—network traffic, keyboard strokes, file-system information, and so on, regardless of whether it needs access to that information. The only restriction: you have to ―promise‖ to play by the rules. If you don’t, you will cause a conflict and crash the entire system.
rootkit technology, resulting in virtualized rootkits. In general we can identify five types of rootkit, ranging from those at the lowest level in firmware (with the highest privileges), through to the least privileged user-based variants that operate in Ring 3.
This makes for a very convoluted and freefor-all environment. Anyone who knows the basic requirements and enough C (a programming language) to be dangerous can develop a kernel driver, load it, and start poking around. Virtualization technologies has introduced new protection rings and thus new instruction sets has been added into the architecture. Essentially it was introduced a Ring –1 (ring negative one) that allows the hypervisor (in most cases, a sleek and minimal host OS) to monitor guest operating systems running in Ring 0, but not ―true Ring 0‖ (thus they are not allowed to use actual hardware, but rather virtualized hardware). These new concepts have also led to significant advancement in
User Mode - Rootkits run in Ring 3, along with other applications as user, rather than low-level system processes. They have a number of possible installation vectors to intercept and modify the standard behavior of application programming interfaces (APIs). Kernel Mode - Run with the highest operating system privileges (Ring 0) by adding code or replacing portions of the core operating system, including both the kernel and associated device drivers. Boot Kits - A kernel-mode rootkit variant called a bootkit is used predominantly to attack full disk encryption systems, for example as in the "Evil Maid Attack", in which a bootkit replaces the legitimate boot loader with one controlled by an attacker; typically the malware loader persists through the transition to protected mode when the kernel has loaded. Hypervisor Level - Rootkits have been created as Type II Hypervisors in academia as proofs of concept, by exploiting hardware virtualization features, this type of rootkit runs in Ring -1 and hosts the target operating system as a virtual machine, thereby enabling the rootkit to intercept hardware calls made by the original operating system.
Issue35 – Dec2012 | Page - 8
Hardware/Firmware A firmware rootkit uses device or platform firmware to create a persistent malware image in hardware, such as a network card, hard drive, or the system BIOS. The rootkit hides in firmware, because firmware is not usually inspected for code integrity.
Usually, when a rootkit infects a host, the workflow is structured as follows: The infection vector allows for rootkit agent reaches victim’s system. (Drive-by-download, client side exploit or a dropper) User-mode agent execution Driver executable decryption and execution System hiding from Kernel-mode. Establishment on the host and Kernel-mode level monitoring/datastealing. Establishment of a covert data channel for network communications.
Rootkits Evolution The earliest type of rootkit consists of replacement programs for commonly used administrative programs on the computer system. The replacement programs hide the activity of the actual payload from the system administrator. These kits are almost exclusive the Unix/Linux family of operating systems. These will be referred to as first generation rootkits. The second generation of rootkits uses ―hooks‖ to redirect application calls to operating system (kernel) functions. The hook is used to intercept such legitimate
function calls and reroute them to the rootkit’s own version of the function. They are more difficult to detect because they have moved a level closer to the kernel. Attackers then began to employ even more sophisticated techniques. Third generation rootkits use techniques that go deeper into the system and modify dynamic data structures in the kernel, the main component of most computer operating systems. Infection vectors for Rootkits are very similar to other high profile malware families currently circulating in the wild. Although not entirely comprehensive, the main distribution methods for rootkits can be split into two categories: 1. Exploit Packs 2. Social engineering Another important aspect to consider is that the Rootkits are very small and subtle and they can sneak past organized defense without notice thanks to their proverbial ability to hide inside other processes or even inside the victim Kernel. The rootkits studied here are very malicious so, in our attempt to uncover their behaviors and their innovative solutions to inject themselves in a victim System, our advisory will describe and compare them trying to offer a clear explanation ―of the way the things are going‖ for all the different types of malware. In this article we depict a series of rootkit representing the second and, the actual, third generation. These malwares have moved to massive deployment and have introduced important modification in their code or in their attacking mechanism. We present ―real life‖ rootkits, caught in the
Issue35 – Dec2012 | Page - 9
wild and studied, as best example of the species:
HackDefender TDSS/TDL/Alureon ZeroAccess
HackerDefender
The configuration file was used for defining all the settings for the rootkit. The modern version is not dissimilar, but instead of using a clear text .ini file it uses a double hook, with a first driver (.dll) used for decryption of the real configuration file.
HackerDefender, was created and released by Holy Father in 2006. At time it became one of the most popular Windows rootkits and has remained one of the most significant piece of malware for Microsoft machines. Main goal for its coder was to ―write something new‖: a userland rootkit easy to configure, to build and to use. It is a persistent, user-mode rootkit that modifies several Windows and Native API functions, which allows it to hide processes, files, registry keys, system drivers and open ports from applications. Despite the small size of its components, HackerDefender is a very complex piece of software so trying to describe its code and its functions is a complex matter that introduces discussion on methods used by rootkits such as Kernel Native API hooking, User Native API hooking, Dynamic Forking of Win32 EXE, Direct Kernel Object Manipulation, and Interrupt Descriptor Table hooking.
Figure 2 - Installation differences between original HackerDefender and modern version (2012)
Like most traditional rootkits, HackerDefender requires administrative privileges to install, this means to do some social engineering via ―phish & scams‖. Once dropped and started the rootkit installs itself as a service that automatically starts at boot. The actual behavior, in this way, is a replica of the older HackerDefender rootkit.
Latest version has introduced a strongest encryption system that makes the reverse a very complex matter.
When launched, the executable creates a system driver (.sys) in the same directory as the executable, loads an encryption/decryption library (.dll) and then loads the configuration file (.ini) before activating its malicious functions.
The original HackerDefender rootkit consisted of two files: one executable file (.exe) and one configuration file (.ini).
It then installs permanently the driver and the library in an hidden folder (random) inside System32 directory and ensure its
Issue35 – Dec2012 | Page - 10
persistence by loading the driver to the following registry keys: HKLM\SYSTEM\CurrentControlSet\Se rvices\[service_name] HKLM\SYSTEM\CurrentControlSet\Se rvices\[driver_name] Additionally, HackerDefender makes sure it will be executed in safe mode by adding the following registry keys:
AdvApi32.dll: Ws2_32.dll: In addition, Hacker Defender installs and loads a kernel-mode driver that implements two support functions utilized by the usermode components. First, it adds system privileges into every process defined as a root process in the configuration file. Second, it helps the rootkit's user-mode components to identify any handle pointing to a hidden object.
HKLM\SYSTEM\CurrentControlSet\Co ntrol\SafeBoot\Minimal\[service_ name] HKLM\SYSTEM\CurrentControlSet\Co ntrol\SafeBoot\Network\[service_ name] Hacker Defender allows the intruder to hide information from other user-mode applications. Criteria for the hidden items are defined in the configuration file. Following items can be hidden:
Files Processes Registry keys and values System services and drivers Allocated memory Handles Inbound and outbound connections
TCP
HackerDefender hides information by modifying the execution path of several Windows and Native API functions. This allows it to alter data passing to and from the hooked function. The rootkit intercepts several system functions in the following libraries: Ntdll.dll: kernel32.dll:
Figure 3– An apparently normal Task Manager in an infected HackerDefender Victim
At time (2006), the malware has generated a lot of hype in the underground, because it has demonstrated the reliability of this type of infection against the kernel, not bad for someone trying to ―write something new…‖ alone. Latest variant of HackerDefender (HacDef, or HxDef, like some Antivirus called it) is yet in-the-wild despite the high ratio of identification.
Issue35 – Dec2012 | Page - 11
TDSS/TDL/Alureon Rootkit.Win32.TDSS is a rootkit that can hide the presence of other malicious programs and provide escalation of privileges on an infected system. It has recently evolved into "bootkit‖ and implements interesting attack mechanisms. The Bootkits are an evolutionary path for the rootkit family that follows the trend of Builder Viruses (such as Zeus, Phoenix, MyWorm, etc ...), malicious programs modularly ―built‖ by the user through a GUI console before the spreading them. This mechanism of malware "building" has become very popular among cyber criminals as the malware is easy to use and offers ample opportunity for dissemination. In addition, the ability of TDSS to work since System boot allows some resilience to the malware against removal. To characterize in a more meaningful way, it should be noted that TDSS is being developed as a framework and is constantly updated and expanded with contributions of people from Eastern Europe but also from China and Latin America. By default, the TDSS is a boot-rootkit with Trojan-clicker module, a module used to hijack the browser and to divert victim internet browsing to predetermined websites.
The vulnerability in question is Windows Task Scheduler Privilege Escalation1. This vulnerability was adopted also in Stuxnet malware. The exploit allows TDSS to install itself on your system without any notification from the system's security and protection tools such as Microsoft UAC (User Account Control). After the launch of the rootkit in the system its process generates a filtered token with privileges "user". This process tries to inject the driver of the print spooler running a set of commands that, if does not complete, terminate with an error (ERROR_ACCESS_DENIED)
Figure 4 - Example of error in Rookit injection routine – memoryStacktrace
The action, if successful, allow the attack to escalate against the system drivers and the installation of malware in specific areas such as the Master Boot Record.
In the version we present, it uses a vulnerability to realize a privilege escalation in 32-bit and 64-bit Microsoft Operating Systems.
Windows Task Scheduler Privilege Escalation, CVE: 2010 - 3888 1
Issue35 – Dec2012 | Page - 12
The default spooler’s file name. When a process invokes the print spooler hooked to the default process name, the antivirus or anti-rootkit in the systems activates a preliminary inspection that, if the action is malicious, returns a notification allowing the user interaction and therefore the possibility of identifying the ongoing attack. This implies that the process spools.exe is linked to the processes of inspection and therefore is active and connected. Figure 5- Malicious Dll recorded during the installation process (Stage 1)
As mentioned above, the rootkit randomly chooses a system driver normally among those present in the folder: %Windows%\System32\Drivers It changes the resource section and use the link inserted to push the system to load a malicious dll. At the same time it modifies the Master Boot Record (MBR) and uses the reserved areas to persist in the system. It is interesting to note that the rootkit installer has a dedicated code that allows it to bypass certain security tools proactively. In fact, today some Antivirus hook function:
The latest versions of TDSS4 have circumvented the problem by hooking the function ntdll.ZwConnectPort at the rootkit startup, verifying the value of the parameter: ServerPortName and when the result shows a result different from: \RPC Control\spoolss this means, to the rootkit logics, the presence of an external element that could intercept the hook function to the spooler and manage it. In this case the malware generates a symbolic link to the main directory of the spoolerss namespace bypassing the inspection by then calling the different function name for the spooler.
NtConnectPort to prevent malware such as TDSS and Stuxnet to inject their payload into spoolsrv. The control made by Antivirus is based on the specific target port that is always: \RPC Control\spoolss
Figure 6- UnicodeStringCheck of ntdll.ZwConnectPort
Issue35 – Dec2012 | Page - 13
To ensure its persistence, (by being loaded at Windows startup), TDSS rootkit uses to infect Windows system drivers. TDSS checks the chain of drivers that handle hard drive I/O looking for last miniport driver object. When found, it infects driver's PE file by overwriting 824 bytes of the resource section. By doing so, it evades a simple check that some antirootkits usually use to detect hidden rootkits: file size cross check. Usually rootkits that infect files can hide their presence by showing the original file instead of the infected one. Antirootkits use raw disk reading techniques. They could read below the filter applied by traditional rootkits and could cross check file sizes looking for discrepancies. TDSS could not be detected by file size cross check because file size of the original and infected files are exactly the same. When the infected driver runs, it executes the 824 bytes loader which then runs the kernel mode component of the infection. It creates a fake driver object, its relative device object, and hijacks every disk I/O communication at the level of drivers's chain where the infected driver was located (i.e. infected driver could be atapi.sys, or iastor.sys).
Figure 7– TDSS I/O HD Driver Miniport Hijacker module
The rootkit intercepts every communication and filters out IRP_MJ_SCSI packets that have specific SRB flags set. By doing so, it hides patched driver on the disk and all disk sectors where its components are located. This is a really effective technique of disk hiding. TDSS rootkit then sets up a Load Image notify routine to intercept every process that loads kernel32.dll library. When intercepted, it injects inside the specified process its user mode components of the infection, tdlwsp.dll, tdlcmd.dll. They are able to turn infected PC in a botnet's zombie. Config.ini, one of the components of the infection, contains settings of the botnet, commands to be executed, bot ID and C&C servers addresses. Communication with C&C servers is SSL encrypted, to evade HTTP filters.
Figure 8– C&C for TDSS connection
TDSS rootkit is indeed a really worrying infection. Some antiviruses may throw up a warning about the presence of tdlcmd.dll or tdlwsp.dll, without being able to do anything.
Issue35 – Dec2012 | Page - 14
Most of times users won't be warned at all, they just don't know their PC is part of a botnet and it is under the control of malware writers which can use their PC as they please. The coders behind TDSS has shown a lot of skills by developing a rootkit to this level of complexity.
The ZeroAccess Rootkit Family ZeroAccess malware family belongs to the Kernel Mode Rootkit category and is a dangerous threat that has been circulating for several years. During that time, ZeroAccess has seen a number of revisions, with modifications to its functionality, its infection strategy and its persistence mechanisms. This rootkit is the youngest of this pool. It has been used as platform to deliver fake Anti Viruses or ―Ransomwares‖ that locks the victim’s machine data and extorts money to release them. In this case the payload delivered is a bot that uses a p2p protocol in order to establish a connection towards other peers that acts as Command and Control (C&C). Our probes have recently showed a proliferation of new variants appearing in the wild. Despite its modification, the core purpose of the Rootkit has remained: to assume full control of the machine by adding it to the ZeroAccess botnet and to monetize the new asset by downloading additional malware. As we said, ZeroAccess is a kernel-mode rootkit, similar to the TDSS (or TDL) family.
The followings are ZeroAccess key features: It uses advanced techniques to hide its presence Is capable of functioning on both 32 and 64-bit Windows Operating Systems from a single installer Contains aggressive self defense functionality And acts as a sophisticated delivery platform for other malware The origins of this rootkit are dated in 2009. Security researchers came across a rootkit able to kill most of security software as soon as they tried to scan specified folders in the system. ZeroAccess was creating a new kernel device object called __max++>, this is the reason why the rootkit has quickly become known in the security field as the ―max++‖ rootkit, also known as ZeroAccess due to a string found in the kernel driver code, presumably pointing to the original project folder called ZeroAccess: F:\VC5\release\ZeroAccess.pdb This rootkit was storing its code in two Alternate Data Streams (ADS), win32k.sys:1 and win32k.sys:2. To avoid being detected, it kills every security software that attempted to scan for alternate data streams. It also created, in the system folder, a number of fake junctions (or reparse points or ―Soft‖ Links) pointing to the fake rootkit device written above. When security software tried to scan such specified folders for ADS presence (FileStreamInformationclass), the rootkit’s self-defense queued a work item in the security process able to immediately kill
Issue35 – Dec2012 | Page - 15
it. It became a non-trivial job scanning the system without being killed. Note:an NTFS junction point is a feature of the NTFS file system that allows a folder to be linked to another local folder, becoming an alias for such target folder. Other than this,ZeroAccess following capabilities:
had
the
Modern persistence hooks into the OS: it is very difficult to remove without damaging the host OS. Ability to use a low level API calls to carve out new disk volumes totally hidden from the infected victim, making traditional disk forensics impossible or difficult. Sophisticated and stealthy modification of resident system drivers to allow for kernel-mode delivery of malicious code. Advanced Antivirus bypassing mechanisms. Anti-Forensic Technolog: ZeroAccess uses low level disk and filesystem calls to defeat popular disk and in-memory forensics tools. Serves as a stealthy platform for the retrieval and installation of other malicious crimeware programs. Kernel level monitoring via Asynchronous Procedure Calls (APC) of all user-space and kernel-space processes and images, and ability to seamlessly inject code into any monitored image At this point we can subdivide the infection into two main phases:
Phase I It looks like the first phase of the infection aims to get a foothold on the victim machine as fast as possible. This phase has definite characteristics that are associated with the ZeroAccess rootkit. The malicious object that does actions in this phase is related with the initial dropper and then with a malicious tampered driver. In the first phase the malware created a fake windows update directory in %SYSTEMROOT%: C:\WINDOWS\$NtUninstallKB[ran dom 5 digit]$ The name of the folder is randomly generated, for example $NtUninstallKB43041$, it presents a random 5 digit string at the end. This mimics a legit Windows Update installation folder in order to hide the rootkit presence into the system. Into this folder the malware saves all the files necessary to its functions and also uses this directory to store additional components such as other malwares and configuration files. With this folder the dropper sets also an Alternate Data Stream resource. The data stream results to be an empty file. We know, that, in some versions, this feature should be a ―bait‖ service used by the rootkit to defend itself. When a driver or an application is caught opening the ADS on that service, the process is killed. The fact that this stream is empty leads us to think that this functionality was deactivated.
Issue35 – Dec2012 | Page - 16
Figure 11 - DAC Figure 9 - Alternate Data Stream
In addition, the malware protects the access to the folder by using the following mechanisms: 1. Set ―System‖ and ―Hide‖ attributes, in order to hide the folder to Windows Explorer 2. Set a reparse point (or symbolic link) to the C:\Windows\System32\config folder, in order to make the folder inaccessible to programs using standard Windows APIs. For example when a user clicks on the malicious folder it is redirected to the linked path. If the symlink directory is ignored and the full path is provided the encrypted files can also be accessed.
This behavior is related to some variants of ZeroAccess. Successively the malware creates a file with a name randomly generated. The name is under the form of a string of ten numbers, in this case we have: 3362557451 The particularity of this file is that have a ―Zero Byte‖ dimension. At this stage of the analysis we didn’t know what is the purpose of this file. Probably it is related to an abandoned feature. Even this file is protected with the creation of the symlink.
Figure 12- Zero Byte file Figure 10– Symbolic Link
3. Changes the Discretionary Access Control (DAC) grants to the folder in order to negate the access.
The next step is the creation of a subdirectory, of about nine or ten numbers, randomly generated. For example: C:\Windows\$NtUninstallKB32445 $\594894280
Issue35 – Dec2012 | Page - 17
This directory contains other two subfolders, ―U‖ and ―L‖, and two files: @ Desktop.ini
The values modified are: Type data: 0x01 Start data: 0x03 ImagePath data: \? This service refers to the randomly selected driver used that is injected by the dropper.
Figure 13- Malware Generated Files and Folders
The selection of drivers to inject is always done into the C:\WINDOWS\System32\drivers folder.
Not all files are created during this phase; in particular some files in the ―U‖ folder are successively downloaded in the phase two, when the malware connects to the other botnet peers.
The above indicated values means that the driver is a kernel device driver (type 0x01) and it will be loaded on demand (0x03), probably by the infected winlogon.exe process.
In the next step (for reference see figure 14, step 2), the dropper process chooses randomly a driver in the %systemroot%\system32\drivers folder and modifies it is startup data and imagepath into the Registry, in order to survive after reboot.
This driver is overwritten with the malware data (Fig 14, step 3). The original driver is compressed and encrypted into the previously created ―protected‖ folder, into the ―L‖ directory (step 2):
Then executes a remote thread injection into winlogon.exe. This is for load the driver into the kernel memory (Figure 14, step 4). The rootkit, once loaded in kernel memory, uses a proprietary disk I/O redirection framework. This framework is used to control the access to the infected driver. The registry modified values refers to a new service component named as the selected driver: HKLM\SYSTEM\ControlSet001\s ervices\.<drivername> In this case we have monitored that netbt.sys is the selected driver.
C:\Windows\$NtUninstallKB32 445$\594894280\L\xadqgnnk The eight digits file into the folder is randomly generated (in this case xadqgnnk); this is the original driver compressed and encrypted. The eight digits file into the folder is randomly generated (in this case xadqgnnk); this is the original driver compressed and encrypted. Any attempt to read the infected driver would have to traverse the disk redirection, in which the rootkit on the fly decrypts the original file from its protected storage and presents the clean image, thus forging the view of the file to security tools.
Issue35 – Dec2012 | Page - 18
Also, during a reboot the infected file would first load the malicious code in kernel, which can refer to its ―protected‖ folder, and load the original file in kernel, thus ensuring the uninterrupted functionality of the original device.
addresses, the other half are a sort 4 bytes timestamp in order to record the last known IP address. In facts we noticed this file is opened and update after several times, during the infection. The ―@‖ file is structured in the following way (Fig 15): The first 4-tuple of bytes are IP addresses, the second 4-tuple is the timestamp. Then the third 4-tuple is an IP address and so on until the end of file.
Figure 14- Rootkit Operations
After this the selected driver was started and this ends the first phase, in facts the dropper process terminates itself. Phase II The second phase is related to the network communications of the bot and is much closer to the ―Sirefef‖ infection. In this phase the operation are performed by the infected driver that controls the opening and closure of sockets at the Transport Drive Interface (TDI) level. The driver is the kernel-mode module of the infection. This module then opened the file ―@‖ that seems the key to the p2p communication system. According to other analysis this file shall be a binary data file containing a list of 256 peer IP addresses. The file is large exactly 2048 bytes, half of this are the IP
Figure 15 – Hex view of the “@“file
The difference we have noticed versus other analyses is that the IP addresses wrote on the @ file doesn’t have any match with the ones captured by our packet sniffer. We didn’t investigate this anomaly more in deep, but we think that probably such kind of obfuscation has been added to this file. However, we can argue that the malware went through this list attempting to connect to each one. Once a connection was established, it sends some obfuscated commands to retrieve the peer’s contact list and updated its own list in the @ file. It continued to do this for all peers that accepted the connection. It reconnected to the first peer to respond and sends other encrypted commands to download and execute additional files. These additional
Issue35 – Dec2012 | Page - 19
files were stored in the U subdirectory. These files are also encrypted and may be related to additional malware. We still are investigating on the obfuscation algorithm.
this type of fraud determines who will receive the money from the clicks. Obviously this "unique id" is set by the attacker in his favor, so that his count will increase and will receive the money instead of the victim. There are also some malformed DNS lookup requests (sent to 83.133.123.20) as we can see in the scheme below (Step 2):
Figure 16 – Additional Files
Periodically, every 20 minutes or so, this process would be repeated. One of the goals of this rootkit is to create a powerful peer-to-peer botnet, which is capable of downloading additional malware on the infected system. This botnet is reportedly involved in click fraud, downloading rogue antivirus applications, and generating spam. In this analysis we have noticed only the ad-click fraud component. The rootkit works at the Transport Driver Interface (TDI) network layer, bypassing firewalls and security software that don’t monitor network activities at this network level. We can now illustrate the infection process (Figure 18, Step 1). Firstly, the malware contacts /geo/txt/city.php at promos.fling.com to find out its location:
Figure 18- Geolocalization
Next, it makes a number of connections to /count.php at livecounter.co, passing in a unique id (Fig 18, Step 1). The parameter "unique id", is very important because in
Figure 17- Location and DNS Malformed
The rootkit sends an encrypted request to all the servers, the packet is always sent to the remote port TCP 16471. The 18 bytes of data looks encrypted, but elicited no response from the server. Completed this preliminary procedures, the bot begins to contact the Peers with a combination of TCP/UDP connections to receive more lists of servers for fulfill the fraud. So the victim machine sends many UDP encrypted request, and if the peers responds, starts TCP connection on the same port, so it can get encrypted data.
Issue35 – Dec2012 | Page - 20
Figure 19- Packet View
It is worth to mention that the malware sample tested also attempted to download and install an update to the Adobe Flash player, this ties in what was said before in OS Modification on the installation mechanism of infection.
Figure 23 - Adobe Flash player
Figure 20- TCP/UDP Traffic scheme
In the following pictures we show the encrypted payload sent during the p2p communications:
Figure 21 - UDP Payload
Figure 22 - TCP Payload
The rootkit allows the attacker to drop in the system further infections, by downloading and storing the relative files inside the protected folder, so that they become invisible to security software. These dropped files are in the form of kernel mode driver. This is because the main rootkit driver is able to load them from the kernel. This process then leads to set up an architecture that aims to implement the "Click fraud". Click fraud is a type of Internet crime that occurs in pay per click online advertising when a person, automated script or computer program imitates a legitimate user of a web browser clicking on an advertise (or ―ad‖), for the purpose of generating a charge per click without having actual interest in the target of the ad's link. Click fraud is the subject of some controversy and increasing litigation due to the advertising networks being a key beneficiary of the fraud.
Issue35 – Dec2012 | Page - 21
The payload of this ZeroAccess version falls into this category of software, and his way of completing the click is described in the diagram below:
updated and ready, the challenge is not going to end soon… Thanks to all guyz @ Black Sun Labs for supporting us writing the article, and remember ―We will be watching!‖
Stefano “Korolev” Maccaglia stefano.maccaglia@gmail.com
Figure 24 - Ad-Click fraud scheme
Here we can see the mechanism that uses ZeroAccess, by first asking the list of sites where to click, and then click on it pointing to links that are passed in the list with the "unique id" set by the attacker. Scary right?
Stefano is a fifthteen years ICT Security and Networking expert with a long streak of successful international project behind him spanning from Infrastructural Security to DWDM Optical Networking. He’s leading Black Sun crew since its foundation and is constantly involved, as a Chief Research Officer, in cyberwarfare, malware analysis and incident response.
Conclusion Ok, time and space are running out. We hope you like the roundup. Studying malware is a very exciting job, but also a very challenging one and rootkits have a special place in the heart of every malware analyst. Understanding rootkits is often the key to find newest exploits and newest trend used by cybercriminal in massive exploitation. It is like unearth a forgotten treasure or look to an alien specimen, but the rootkit is also extremely dangerous and should be handled with care... Understanding how they work and how they can be identified is the best way to reduce their threat, so keep yourself
Andrea “Felyx_da_Cat” Minghiglioni Andrea is a forensics and malware analyst @Black Sun Labs. He is actually working as a fraud and incident analyst in the Incident Response Team of an international financial institution. During the years he has dissected many worms, rootkits and trojans, and has developed a peculiar love for mutex.
Issue35 – Dec2012 | Page - 22
Hijacking Bluetooth Headset [Note: This demonstration is based on article ―Bluetooth Reconnaissance – Watching over Invisible and Cloning Bluetooth Device‖. Please go through it before moving forward] Well for this demonstration, we are using following devices and tools:
Bluetooth Headset External Bluetooth Dongle Laptop with BackTrack 5 R3
In this section we will see how to remotely inject audio in Bluetooth headset and also record the audio from it.
If you observe clearly hci0 settings, it is ―Miscellaneous‖ type device, which is not compatible with Bluetooth headsets. So with this setting it will not be possible to establish connection with Bluetooth Devices. So here we need to change its class to audio/video device type which can work with Bluetooth headset. #hciconfig 0x200404
hci0
class
First we will make our Bluetooth device up and running. #hciconfig hci0 up
Now if we observe the settings of hci0 interface, it’s changed to device type info ―Device conforms to the Headset Profile‖.
Issue35 – Dec2012 | Page - 23
And now #./carwhisperer<interface><injec ting audio file><Output file><victim BD_ADDR>
Here notice that BD_ADDR of interface is 00:07:AB:FF:CF:87
hci0
Game Over!
Now we will create folder with this BD_ADDR in /var/lib/Bluetooth directory. Then in this BD_ADDR folder we will create text file named ―pincodes‖ in which we will assign 0000pincode for Bluetooth headset on which we are going to inject audio.
Here we successfully injected our own message in headset. And the output will be stored in out.raw file. For injecting audio we require the .raw format files. SOX is nice tool for audio conversions. We can convert audio wave files into raw and vice versa. To perform this attack more smoothly and from a long distance you can buy very longrange Bluetooth dongle. Like AIRcable
Here we made scan for finding BD_ADDR of our Bluetooth headset victim. And we got 12:01:07:00:01:E7 Bluetooth Headset. So now we are with all required setup. It’s time to play with our little Bluetooth headset victim.Here we go… For this attack we will use the tool ―carwhisperer‖. Download url: http://trifinite.org/Downloads/carwhispere r-0.2.tar.gz
Swaroop D. YermalkaR swaroop.wireless@gmail.com Swaroop is an Engineering student from M.I.T.College of Engineering, Pune. He is enthusiastic and hobbyist for Infosec.
Issue35 – Dec2012 | Page - 24
Identify Web Application Vulnerabilities using OWASP ZAP
automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
Main Features of ZAP Introduction Today’s organizations are facing major problems with Web Application Vulnerabilities. Many of such Web app vulnerabilities resulted in compromise of systems, including financial damage, theft of credit cards, loss of confidential data and reputational damage. Sometimes you just need to browse a site to compromise whole organization’s network, it’s that simple. Period. But thanks to the folks at OWASP, we can find flaws in web applications before bad guys do, by using the tool ZAP. In this article we are going to learn ―how to identify flaws in your applications using ZAP‖.
“ You cannot build secure web applications unless you know how to attack them ” OWASP Zed Attack Proxy provides an easy to use integrated penetration testing tool for testing web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who a new to penetration testing. ZAP provides
Intercepting Proxy: An Intercepting proxy is a tool which sits in between your browser and web server, It allows you to see all of the requests you make to a web app and all of the responses you receive from it. which also allows you to intercept the requests and responses. Active or Automated Scan: Active scanning attempts to find the vulnerabilities which are listed in owasp top 10 of selected target . It uses default attack scenarios to find the vulnerabilities. Passive scanner: Passive Scanner scans all of the responses from the web application being tested in the background by raising potential issues without intercepting any requests/responses. Brute Force scanner: This features allows to Brute force directories and files using a set of dictionaries provided, which contains a large number of files and directory names.
Issue35 – Dec2012 | Page - 25
Spider: Spider is a tool that is used to automatically discover new URL’s and crawls through all the identified hyperlinks in the page and adds them to the list of URLs, the process continues recursively as long as new resources are found. Fuzzer: Fuzzing is a process of finding bugs/crashes by providing invalid or unexpected data to the target server. Dynamic SSL certificates: ZAP can generate self signed certificates, which allow you to send and receive data by encrypting/decrypting them from server using man in the middle approach. API: An Application Programming Interface (API) which allows you to interact with ZAP programmatically. Beanshell integration: The BeanShell is an interactive Java shell that can be used to execute BeanShell scripts.
Reporting The important part once after performing the pentest is reporting. The ZAP tool provides a good reporting feature which allows you to generate a report of the vulnerabilities identified. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution. To generate a report, select Report → Generate HTML Report and specify the desired location to save the file.
ZAP Extensions One of the best feature in ZAP is adding extensions which adds additional features to ZAP suite. Visit below link more about extensions: https://code.google.com/p/zap-extensions/
Conclusion ZAP is a free and open source software which is developed for the community by the community. It can be used by beginners to learn pen testing, Developers can use it to secure their web apps and for security pros to use it for auditing the security stance of an application. Zap is a unique and key project of OWASP with an active community. Note: The tools are able to find vulnerabilities based on predefined test cases. However, there are certain vulnerabilities that none of the tools can find like logical bugs, misconfigurations etc. Automated tools tend to generate false positives, which must be verified manually.
Raghu Nath raghunath24@gmail.com Raghu Nath is a security enthusiast, presently working as Information Security Analyst at Entersoft Information System Pvt LTD.
Issue35 â&#x20AC;&#x201C; Dec2012 | Page - 26
Social Media & Indian Cyber Law In India, there has been a lot of controversy over the last few months over Section 66A of the Indian Cyberlaw being the amended Indian Information Technology Act, 2000 on different occasions. In Professor AmbikeshMahapatra case, Professor AmbikeshMahapatra was arrested on account of forwarding of caricature/cartoons on Facebook. Further, Ravi Srinivasan Twitter case showed how on a complaint, a personâ&#x20AC;&#x2122;s tweets could be brought within the ambit of Section 66A of the amended Indian Information Technology Act, 2000. In K V Rao case, two men K.V. Rao and Mayank from Mumbai, were arrested for allegedly posting offensive comments against some leaders on their Facebook group. The recent case pertaining to ShaheenDhada, where two girls were arrested for Facebook post and its liking
respectively, has become the talking point for all users.
In the last few days, we have been seen various discussions about defective IT legislation in India and how there is a need for changing the same. This article aims to explain in common man's language what is Section 66A of the amended Indian Information Technology Act, 2000 all about? Section 66A makes it an offence when you send, by means of a computer resource or communication device, any of the following information: 1) any information that is grossly offensive; 2) any information that has menacing character; 3) any information which you know to be false but which is sent for purpose of causing annoyance; 4) any information which you know to be false but which is sent for purpose of causing inconvenience;
Issue35 â&#x20AC;&#x201C; Dec2012 | Page - 27
5) any information which you know to be false but which is sent for purpose of causing danger; 6) any information which you know to be false but which is sent for purpose of causing obstruction; 7) any information which you know to be false but which is sent for purpose of causing insult; 8) any information which you know to be false but which is sent for purpose of causing injury; 9) any information which you know to be false but which is sent for purpose of causing criminal intimidation; 10) any information which you know to be false but which is sent for purpose of causing enmity; 11) any information which you know to be false but which is sent for purpose of causing hatred; or 12) any information which you know to be false but which is sent for purpose of causing ill will. All the above as per (3) to (12) must be done persistently by using a computer resource or communication device. 13) any e-mail or electronic mail message for the purpose of causing annoyance; 14) any e-mail or electronic mail message for the purpose of causing inconvenience; 15) any electronic mail or electronic mail message to deceive the addressee or recipient about the origin of such messages; 16) any e-mail or electronic mail message to mislead the addressee or recipient about the origin of such messages.
So if you are a social media user or even if you are a user of a computer system or mobile, be careful! You could be brought within the ambit of this Section 66A of the amended Indian Information Technology Act, 2000. To help understand the scope of Section 66A of the amended Indian Information Technology Act, 2000, letâ&#x20AC;&#x2122;s try to examine some common illustrations of acts, which could come under Section 66A of the amended Indian Information Technology Act, 2000. When you send either by means of a Computer, Computer System, Computer Network or using Mobile Phone, Smart Phone, iPhone, iPad, Tablet, Smart Devices, Personal Digital Assistants, BlackBerry or any other communication devices, the following kind of information, you could be covered under Section 66A of the amended Indian Information Technology Act, 2000:1) If you swear or abuse somebody, the said swear words could be said to be grossly offensive. The same could also be said to be having menacing character and your act could come within the ambit of Section 66A(a) of the amended Indian Information Technology Act, 2000. 2) Anything defamatory which affects the character, reputation, standing or goodwill of a person could also be deemed to be grossly offensive. 3) Making false allegations against the character of a person or character assassination could also qualify as grossly offensive and having menacing character.
Issue35 – Dec2012 | Page - 28
4) Using insulting words or symbols which are obscene, could also qualify as grossly offensive and having menacing character. 5) Calling someone names could also be brought within the ambit of being grossly offensive or having menacing character 6) Posting the picture of a person in uncomplimentary situations and environments could also be said to be grossly offensive or having menacing character. For example, if you morphed the photograph of a girl/boy’s face on the face of erotic/nude model’s body, the same could not only be obscene but could also be grossly offensive and having menacing character. 7) Electronic morphing which shows a person depicted in a bad light could also be seen as an example of information being grossly offensive or having menacing character. 8) Using vernacular gallies or bad words in English alphabets could also qualify as grossly offensive or having menacing character. 9) Threatening somebody with consequences for his life, apart from being separate offences, could be also construed as information which is grossly offensive or having menacing character. 10) Threatening to expose the ill-deeds of somebody could also qualify as information which has menacing character. 11) Information containing malicious, mischievous character assassination 12) Information containing morphed pictures aimed at hurting religious sentiments.
13) Information showing gods and goddesses of particular religions in an uncomplimentary light. 14) Putting the picture of a person against a slogan/phrase/saying which does not depict his true character or personality. 15) Deceiving the addressee or recipient about the origin of such messages. For example, sending emails from a fake email account to another person, could qualify as an offence under Section 66A of the amended Indian Information Technology Act, 2000. 16) Further misleading the addressee or recipient about the origin of such messages, e.g. sending e-mails and SMSs in the name of Reserve Bank of India for big lotteries, could also be brought under Section 66A of the amended Indian Information Technology Act, 2000. 17) E-mail containing fake recruitment offers to unsuspected members of the public, could also qualify as an offence under Section 66A of the amended Indian Information Technology Act, 2000. The aforesaid are just some illustrations to demonstrate how broad Section 66A of the Indian Information Technology Act, 2000 is and how and in what particular comprehensive manner can it impact you and your life. The said illustrations are neither comprehensive nor complete but have been given as selective examples of the ambit of Section 66A of the amended Indian Information Technology Act, 2000, for academic, research and review purposes only.
Issue35 â&#x20AC;&#x201C; Dec2012 | Page - 29
The language and scope of legal terms used under Section 66A are very wide and are capable of distinctive varied interpretations. Seen from another angle, Section 66A can be effectively used as a tool for gagging legitimate free online speech. The problem under Section 66A is that it comes up with extremely wide parameters which have not been given any specific definitions under the law. These parameters are capable of being interpreted in any manner possible, by the law-enforcement agencies. As such, while Section 66A talks about sending any information that is grossly offensive or having menacing character, the law does not give any guidance as to what is grossly offensive or information having menacing character. Thus, it is left to the subjective discretion of the law-enforcement agencies in this regard. All wide meaning terms used under Section 66A have not been defined, which itself provides huge amount of flexibility in Section 66A to be used in any circumstances perceivable. Thus, large portions of legitimate free online speech could also be brought within the ambit of Section 66A of the amended Indian Information Technology Act, 2000. Given the advent of technology and the way people are misusing the same, there could be millions of situations which could qualify as offences under Section 66A of the amended Indian Information Technology Act, 2000.
Lessons The lessons from Section 66A of the amended Indian Information Technology Act, 2000 are that till such time Section 66A is either changed, modified, varied or amended, it will be imperative that you exercise due diligence when you send
information on the Internet, social media & mobile networks. Kindly note that the focus of the law under Section 66A of the amended Indian Information Technology Act, 2000, is not on publishing information, the focus is on the offence of sending information. This assumes more significance, since whenever you are on the Internet or when you are sending e-mail or posting or publishing a blog or creating an SMS, as you are sending these electronic records from your computer system or communication device. Hence, be very careful before you send information on electronic platforms and computer networks.
Conclusion There are tremendous problems in the way Section 66A of the amended Indian Information Technology Act, 2000 has been drafted. This provision even though has been inspired by the noble objectives of protecting reputations and preventing misuse of networks, has not been able to achieve its goals. The language of Section 66A of the amended Indian Information Technology Act, 2000 goes far beyond the reasonable restrictions on free speech, as mandated under Article 19(2) of the Constitution of India. For India, being the worldâ&#x20AC;&#x2122;s largest, vibrant democracy, reasonable restrictions on free speech need to be very strictly construed. Section 66A of the amended Indian Information Technology Act, 2000 has the potential of prejudicially impacting free speech in the digital and mobile ecosystems. Section 66A of the amended Indian Information Technology Act, 2000 needs to be amended to made the Indian Cyber Law in sync with the principles enshrined in the Constitution
Issue35 â&#x20AC;&#x201C; Dec2012 | Page - 30
of India and also with the existing realities of social media and digital platforms today. If you require more information on the above, the author PavanDuggal, Advocate, Supreme Court of India, could be contacted at pavan@pavanduggal.net and pduggal@gmail.com.
Pavan Duggal Advocate, Supreme Court of India Head, Pavan Duggal Associates While a practicing Advocate, Supreme Court of India, Pavan Duggal has made an immense impact with an international reputation as an expert and authority on Cyber law and ECommerce law. An internationally renowned expert and authority on Cyberlaw, Pavan has also the credit of having done pioneering work in the field of Convergence Law and Mobile Law.
Issue35 â&#x20AC;&#x201C; Dec2012 | Page - 31