Issue35 Dec2012 | Page - 1

Issue35 Dec2012 | Page - 2

Issue35 Dec2012 | Page - 3
Rotten to the coreA
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.
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.
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.
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.
Later, however, this kind of tools has grown
in sophistication, changing its targets.
Windows users have become the primary
targets, and the Rootkits have escalated the
cybercriminal world.
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

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 so-
called 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







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 03) 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.










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
Else
End If
If fuckingprocesses("VMwareUser.exe") = True Then
MsgBox "Caused exception at 0x44e85c", vbCritical, "VMware"
End
Else
End If
End Sub
Figure 1 - Rings

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 higher-
privileged 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 datanetwork 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 dont, you will cause a
conflict and crash the entire system.
This makes for a very convoluted and free-
for-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
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.
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 victims
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/data-
stealing.
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
rootkits 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
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.
Latest version has introduced a strongest
encryption system that makes the reverse a
very complex matter.
The original HackerDefender rootkit
consisted of two files: one executable file
(.exe) and one configuration file (.ini).
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.

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.
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.
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:
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 TCP
connections
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:
AdvApi32.dll:
Ws2_32.dll:
In addition, Hacker Defender installs and
loads a kernel-mode driver that implements
two support functions utilized by the user-
mode 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.
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.
Figure 3 An apparently normal Task Manager in an
infected HackerDefender Victim

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.
In the version we present, it uses a
vulnerability to realize a privilege escalation
in 32-bit and 64-bit Microsoft Operating
Systems.
The vulnerability in question is Windows
Task Scheduler Privilege Escalation
1
.
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)
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.





1
Windows Task Scheduler Privilege Escalation,
CVE: 2010 - 3888
Figure 4 - Example of error in Rookit injection
routine memoryStacktrace

Issue35 Dec2012 | Page - 12

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:
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
The default spoolers 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.
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.

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).




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.
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.
Figure 7 TDSS I/O HD Driver Miniport Hijacker
module
Figure 8 C&C for TDSS connection

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 victims 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
rootkits 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 had the
following capabilities:
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
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.
3. Changes the Discretionary Access
Control (DAC) grants to the folder in
order to negate the access.



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 didnt 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.
The next step is the creation of a
subdirectory, of about nine or ten numbers,
randomly generated. For example:
C:\Windows\$NtUninstallKB32445
$\594894280


Figure 9 - Alternate Data Stream
Figure 10 Symbolic Link
Figure 11 - DAC
Figure 12- Zero Byte file

Issue35 Dec2012 | Page - 17
This directory contains other two sub-
folders, U and L, and two files:
@
Desktop.ini
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.
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.
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.
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.
The selection of drivers to inject is always
done into the
C:\WINDOWS\System32\drivers
folder.
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.
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):
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.
Figure 13- Malware Generated Files and Folders

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.
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
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.
The difference we have noticed versus other
analyses is that the IP addresses wrote on
the @ file doesnt have any match with the
ones captured by our packet sniffer. We
didnt 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 peers 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
Figure 14- Rootkit Operations
Figure 15 Hex view of the @file

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.
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 dont 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:
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
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):
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.




Figure 16 Additional Files
Figure 18- Geolocalization
Figure 17- Location and DNS Malformed

Issue35 Dec2012 | Page - 20

Figure 19- Packet View
In the following pictures we show the
encrypted payload sent during the p2p
communications:

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.

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.
Figure 20- TCP/UDP Traffic scheme
Figure 21 - UDP Payload
Figure 22 - TCP Payload
Figure 23 - Adobe Flash player

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:
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?
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
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










Andrea Felyx_da_Cat Minghiglioni




Figure 24 - Ad-Click fraud scheme
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. Hes leading
Black Sun crew since its foundation and is
constantly involved, as a Chief Research
Officer, in cyberwarfare, malware analysis
and incident response.
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.
First we will make our Bluetooth device up
and running.
#hciconfig hci0 up


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 hci0 class
0x200404

Now if we observe the settings of hci0
interface, its changed to device type info
Device conforms to the Headset
Profile.


Issue35 Dec2012 | Page - 23

Here notice that BD_ADDR of hci0
interface is 00:07:AB:FF:CF:87

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 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. Its
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
And now
#./carwhisperer<interface><injec
ting audio file><Output
file><victim BD_ADDR>
Game Over!
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 long-
range Bluetooth dongle. Like AIRcable

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
Introduction
Todays 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
organizations network, its 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
automated scanners as well as a set of tools
that allow you to find security
vulnerabilities manually.
Main Features of ZAP
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 URLs
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 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 persons 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 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, lets 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/boys face on the face of
erotic/nude models 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 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
worlds 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 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 E-
Commerce 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 Dec2012 | Page - 31