Quantcast
Channel: MalwareTech
Viewing all 139 articles
Browse latest View live
↧

Win64/Vabushky - The Great Code Heist

September 2, 2013, 7:09 pm
$
0
0

Introduction

This analysis is of a new winlocker dropper that was first seen in the wild last month, the binary is 64 bit, packed with MPRESS, and contains 3 local privilege escalation exploits (CVE-2013-3660, CVE-2012-1864, and CVE-2012-0217), as well as the PowerLoader injection method. 2 of the exploits and the powerloader injection were stolen from carberp leak. I, as well as a few others, thought the dropper may be PowerLoader, however I now have my doubts, I will explain why at the end.

Data Gathering

The first thing the loader does is query some system information, then post it to the command and control server (C&C).

The function I have named "PostArch" simply posts the string "x64" to the C&C, the rest of the functions query the version information of the following file: win32k.sys, ntoskrnl.exe, ntkrnlpa.exe, ntkrnlmp.exe, and ntkrpamp.exe, then post it to the command and control.
The first header is for the "PostArch" function, the second is for the rest. Any data is url encoded so the file version data is "f=win32k.sys&v=6.1.7600.16617&", this format is used for every file and the last "&" doesn't do anything but the coder appends it anyway.

Exploitation

The loader will inject into explorer using an x64 version of the infamous Shell_TrayWnd Injection (Explained Here). Once inside explorer the first exploit is executed, if it fail: the next one is executed, and so on. 

The code flow of the elevation attempt
The exploits are as follows:
  • EPATHOBJ::pprFlattenRec (CVE-2013-3660)
  • String Atom Class Name (CVE-2012-1864)
  • (Intel / x64) SYSRET (CVE-2012-0217)                                  
Each exploit will try to elevate the process privileges, if successful, a dll will be written to the temporary directory, under the name "dll.dll", then executed (The dll is also packed with MPRESS).

Let's take take a look at the dll after unpacking. 
The real entry point of the packed dll
All that is happening here is the dll makes sure the "fdwReason" parameter of the entry point is "DLL_PROCESS_ATTACH" (The dll is being loaded). Next it gets the full path to the process that the dll is currently loaded in, then signals an event to notify the main process that the load was successful. After this, the filename is extracted from the file path and stored in the RSI register.

Let's take a look at what is does with this value.

First check (Are we in logonui process)
Second check (Are we in utilman process)
The jump destination if we are inside utilman or logonui
Here the dll checks if the operating system version is 6 and platform id is "VER_PLATFORM_WIN32_NT", which makes sure the OS is Vista+, then attempts to get the process id of its parent, followed by suspending all threads inside the parent process. If any of the following operations fail, it just skips ahead to the next stage.


This is the last stage, here the dll extracts and drops a second dll to "C:\Windows\System32\vBszKyhVp.dll". The loader then looks for an svchost process running as "NETWORK SERVICE", opens a handle to the process, allocates some memory inside, writes the dll path to the allocated memory, and calls "RtlCreateUserThread". The thread start address is set to the address of "LoadLibrary" and the parameter set to address of the allocated memory, as a result the thread in svchost will call loadlibrary with the dll path set to the path of the dropped dll, which will cause the process to load the dll.

The 2nd dll is responsible for downloading some images and installing a winlocker, it is also packed with MPRESS, I'll probably reverse it and write about it in a part 2.

Why I'm not sure this is PowerLoader

Basically the code seems too closely related, the first dropper creates an event that is then signaled by the 1st dll that is dropped, the dll also checks what process it is in, which could change based on which exploit was successful. The way that the dll interacts with the dropper makes me think that they were both coded by the same person. As well as this, the dropper sets a registry key with the screen resolution, which is used by the locker to get the correct size screen-lock image, this rules out the 1st dll being part of the PowerLoader dropper.

Originally, what made me think it was PowerLoader was the string that said "powerloader".

After a while reversing this sample, I realized that the string is probably just referring to the elevation method used, seeming as this code indicates which method was successful (atom exploit, sysret exploit, epathobj exploit, powerloader injection). To me, it seems more likely that this is all part of the same project and most of the primary dropper code was stolen from carberp.

Possibly more exploits to come

I did notice a few bits of unused code in the dropper that seemed to imply more exploits were on the way.

Checking if the process is sysprep then exiting

Exports for UAC Injection

These 2 images make me think the coders are in the process of implementing a user account control bypass, there is a public bypass that exploit auto-elevating processes on windows 7 (sysprep being one of them). Also, earlier in the article i showed 2 checks (one for logonui.exe and one for utilman.exe). The atom exploit (CVE-2012-1864) will result in the dll getting loaded into logonui process, however, none of the exploits seem to load the dll into utilman, which leads me to think they were testing another exploit.

Conclusion

The Shell_TrayWnd Injection and CVE-2012-1864 + CVE-2012-0217 were both taken from the carberp leak (this is probably the biggest theft of code from the leak that i have seen so far). Because the winlocker component seems interesting, I will likely write a part 2 and reverse it.

Thanks to R136a1 for the sample and collaboration on reversing. :)







↧
Search

Fighting Hooks With Hooks - Sandbox Escape

September 17, 2013, 2:58 am
$
0
0

Introduction

I was pretty bored today and couldn't think of an article to write, decided I'd come up with an example of escaping a sandbox. Most sandboxes use hooks placed within user-mode dlls in order to monitor process activity. If someone was able to remove or bypass these hooks, they would be able to escape the sandbox.

A common method used by advanced malware is to write a custom implementation of "LoadLibrary" / "LdrLoadDll". Using this code they can manually map a new, clean, copy of a dll and use it to evade hooks. Because of the nature of PE files, it is generally quite complex to do this and required a good understanding of PE files and the PE loader. As it happens, there is currently no working, easy to find, code to do this on Google, so such methods are not seen is script-kiddie malware and I'd like to keep it that way. Instead I will be showing a nice little hack that works in a similar way, however will be fairly easy for sandbox developers to deal with. 

How It Works

When i was thinking of which way to attack the sandbox, I thought it would be amusing (at least for me) to use hooks to facilitate the escape, I managed to do it using a single hook: "RtlEqualUnicodeString".

First, if we look at the call path for "LoadLibrary" we will see it eventually ends up at "LdrLoadDll" which internally calls "LdrpLoadDll". Inside "LdrpLoadDll" is a call to LdrpCheckForLoadedDll, this function is responsible for iterating through the list of currently loaded dlls ("PEB_LDR_DATA->InMemoryOrderModuleList") and checking that the target dll isn't already loaded.

A snippet from LdrpCheckForLoadedDll

By hooking "RtlEqualUnicodeString" or "RtlCompareUnicodeString", which is called internally by "RtlEqualUnicodeString", we can trick LdrpLoadDll into loading an already loaded dll. Because of the way "GetModuleHandle" works, any subsequent calls will return a handle to the original dll and not our new one. 

Now that we can trick the loader into loading new dlls, we can load a new copy of ntdll which will not be hooked. Using the address returned by "LdrLoadDll", we can call "GetProcAddress" to get a pointer to "RtlCreateUserProcess" within the new dll. Now we can create a new process whilst bypassing any hooks to catch new process creation.

Prevention

This method can easily be prevented by using a hook within LdrLoadDll. Each time LdrLoadDll is called, check if the name is that of a module we need to hook, if it is, call the original LdrLoadDll, then pass the address returned to the hooking function. Remember, we cannot use GetModuleHandle or equivalent.

An Example


Process with 2 copies of ntdll loaded



↧
↧

Ring3 / Ring0 Rootkit Hook Detection 1/2

September 23, 2013, 7:25 pm
$
0
0

Introduction

The cybercrime underworld hasn't given me any exciting malware to reverse and I'm running out of ideas for new posts, so I'm going to do a 2 part article about the techniques used by rootkits to intercept function calls, and how to detect them. The first part will explain some hooking methods, the second part will explain how to detect them. As I haven't done any kernel mode stuff on this blog, I will be looking at both user mode and kernel mode hooks on a x86 windows system. 

Execution Flow

In order to get a better understanding of the attack surface, I've made a simplified flow chart of a call to the WriteFile function in kernel32.dll. This is just an example to highlight key points, I chose the WriteFile function as it makes for a nice example, and disk I/O is commonly intercepted by malware, however most of the stuff on this graph will apply to lots of functions. 

If you haven't realized you can click the image to make it bigger, this article probably isn't for you.
(1)
  • WriteFile is just a simple wrapper for NtWriteFile. 
  • Can be hooked with inline, IAT or EAT hooks. 
  • Hooking this function will intercept all calls to WriteFile in whichever process the hooks are placed.
  • All paths used inside kernel32 are generally Dos Paths (C:\file.txt).

 

(2)
  • NtWriteFile is a small stub that sets the EAX register to a 32bit value (I'll explain this value later), then calls KiFastSystemCall. 
  • Can be hooked with inline, IAT, or EAT hooks. 
  • Hooking this function will intercept all calls to CreateFile, NtWriteFile or ZwWriteFile in whichever process the hooks are placed.
  • All paths used by ntdll file functions are generally NT Paths (\??\C:\file.txt).
(2.1)
  • In order to call KiFastSystemCall NtWriteFile moves the address 0x7FFE0300 (KiFastSystemCall / KiFastSystemCall Pointer) into the EDX register, then it does "call edx" or "call dword ptr [edx]"
  • The rootkit could replace the address 0x7FFE0300 within the NtWriteFile function body in order to hook it.
  • Hooking this function will intercept all calls to CreateFile, NtWriteFile or ZwWriteFile in whichever process the hooks are placed.
  • All paths used by ntdll file functions are generally NT Paths (\??\C:\file.txt).

 

(3)
  • KiFastSystemCall is a small stub that moves the stack pointer into the EDX register then executes the sysenter.
  • The stub is only 5 bytes in size and the last instruction (RETN) is pointed to by KiFastSystemCallRet, this only leaves 4 writable bytes (not enough space for a near call/jmp). Furthermore, the address is hard-coded which makes IAT or EAT hooks impossible. 
  • Sometimes the KiFastSystemCall stub resides in KUSER_SHARED_DATA, in which case it is not writable from usermode. 
  • By hooking this function, the rootkit gains the ability to intercept all user mode calls to kernel functions.

 

(4)
  • The SYSENTER instruction is what transfers execution from user mode to kernel mode, in order to execute an kernel function. when the instruction is executed, the CPU sets the code segment to the content  of the SYSENTER_CS register, the stack pointer to the content of the SYSENTER_ESP register, and the EIP to the content of the SYSENTER_EIP register. The SYSENTER_EIP register points to the KiFastCallEntry function ntoskrnl, as a result of this, the cpu will begin executing KiFastCallEntry.
  • These registers are known as MSRs (Model Specific Register), they are only readable by using the cpu instruction RDMSR (Read MSR) and writable using the WRMSR (Write MSR) instruction. These instructions are both privileged (can only be executed from ring 0) therefore, in order to hook, a kernel driver must be loaded.
  • By modifying the SYSENTER_EIP, the rootkit gains the ability to intercept all user mode calls to kernel functions, but we cannot intercept any kernel mode calls, because only user mode call use SYENTER.

 

(5)
  • KiFastCallEntry is responsible for taking the 32bit value from the EAX register (this is the value we mentioned in 2). The first 11 bits are the ordinal of the SSDT function to use (SSDT_Address+(Ordinal*4)), the 12th and 13th byte determine which SSDT to use, the rest of the bits are ignored. Once the function has worked out which SSDT to use, it calls the address at the given ordinal in the table.
  • Can be hooked with an inline hooks.
  • By hooking this function, the rootkit can intercept all user mode calls to kernel functions, as well as all kernel mode calls to functions starting with Zw, but not those starting with Nt.
(5.1)
  • Because the SSDT is a table of function pointers, it is also possible to hook calls by replacing the pointer within the SSDT. For every kernel function in ntdll, there is an equivalent pointer within the SSDT, therefore we can hook any function at will just by replacing the pointer. We are also able to hook all kernel mode calls to functions starting with Zw using this method, however, we cannot hook kernel mode calls to functions starting with Nt.

 

(6)
  • NtWriteFile...Again. We saw a call to NtWriteFile in 2, however that was just an ntdll.dll stub to enter into kernel mode, this is the actual NtWriteFile call pointed to by the address at the given SSDT ordinal.
  • NtWriteFile builds an IRP (I/O Request packet) and supplies it to IopSynchronousServiceTail, it also passes a device object associated with the file being written.
  • Can be hooked with an inline hook.
  • By hooking this function, the rootkit can intercept user mode and kernel mode calls to NtWriteFile and ZwWriteFile.

 

(7)
  • IopSynchronousServiceTail may only be used on certain versions of windows, it is just a simple wrapper for IofCallDriver, so I'll skip this.

 

(8)
  • IofCallDriver takes a device object pointer (PDEVICE_OBJECT) and IRP pointer (PIRP) (both supplied by NtWriteFile). The device object contains a pointer to the driver object of the driver associated with that device (PDRIVER_OBJECT). The driver object contains a member called "MajorFunction", this is an array of 28 driver defined function pointers (a bit like an EAT or the SSDT), Here is a full list of IRP major function names. IofCallDriver will call one of the IRP major functions, based on which one is specified by the "MajorFunction" member in the IO_STACK_LOCATION for the supplied IRP.

    In the case of file operations, the device object given by NtWriteFile will nearly always be \filesystem\ntfs (aka ntfs.sys) or a filter device attached to \FileSystem\Ntfs, because filter drivers pass on the call to the device below below them until it gets to \FileSystem\Ntfs, we can assume the call will always end up at \filesystem\ntfs unless one of the filter drivers cancels it.
  • By hooking IofCallDriver, the rootkit can intercept practically any call to any driver. In order to only intercept calls to a certain driver, the rootkit can check the "DriverName" member pointed to by the driver object which is pointed to by the device object. Alternatively to intercept calls to a certain device, the rootkit could call ObQueryNameString on the device object (It is important to note that not all devices have names). The rootkit can also filter only specific IRP major function calls, this is done by calling "IoGetCurrentIrpStackLocation" on the IRP pointer, then checking the "MajorFunction" member of the returned IO_STACK_LOCATION. 

 

(9)
  • The IRP_MJ_WRITE function is responsible for writing files within the filesystem. 
  • By attaching a filter device to the device stack of \FileSystem\Ntfs or by replacing an IRP major function pointer with one of its own, the rootkit can intercept any call to \FileSystem\Ntfs. In order to intercept NtWriteFile calls, the rootkit would need to inspect IRP_MJ_WRITE calls in the filter device, or replace the IRP_MJ_WRITE pointer in the driver object.

 

(10)
  • This refers to the volume and partition drivers that are used by \FileSystem\Ntfs, these are not normally targeted by rootkits, therefore i have left them out. 
  • These drivers can be hooked in the same way as 9.

 

(11)
  • The NTFS filesystem uses the IRP_MJ_WRITE major function of the class driver "\Driver\Disk" aka disk.sys, in order to write a disk. Because \Driver\Disk is much lower level than the NTFS filesystem driver, there are no file name, instead it is only possible to work with LBAs (Logical Block Addresses). Logical Block Addressing in a linear method of addressing the disk by sectors, each sector is usually 512, 1024, 2048, or 4096 bytes. The sector number starts at 0 (Master Boot Record) and goes up to whatever, depending on the size of the disk.  
  • Hooking of drivers lower than ntfs.sys is usually only seen in kernel mode payload drivers used by bootkits. This is due to the fact that bootkits tend to only work with files outside of the NTFS filesystem, therefore not having to worry with translating file names to LBAs.  

 

(12)
  • The disk subsystem refers to any driver(s) below disk.sys, generally this a port/miniport driver, which is a hardware or protocol specific driver. In most cases this will be atapi.sys or scsiport.sys which are for ATA and SCSI complaint disk devices. 
  •  At this level a new IRP major function is used, IRP_MJ_SCSI, which is an alias for IRP_MJ_INTERNAL_DEVICE_CONTROL. Here, the rootkit will have to work with SCSI_REQUEST_BLOCK parameters, which further complicates things compared to a disk.sys hook. 
  • Any port/miniport hooks are usually only found in advanced kernel mode payload drivers used by bootkits. 

Clarification

  • The term "kernel function" refers to any function beginning with Nt or Zw. I call these kernel functions because the code resides in the kernel, for a user mode application to call one of these functions, it must enter the kernel via SYSENTER.
  • Only 1, 2, and 3 can be hooked from user mode, the rest require a kernel mode driver.
  • The reason hooks places at 5 and 5.1 cannot intercept kernel mode calls to functions starting with Nt is due to how these functions work. Any function beginning with Nt, when called from kernel mode refers to the actual function within ntoskrnl. However, when a function beginning with Zw is called from kernel mode, it sets the EAX register to the same number that was set in 2, then it calls KiSystemService. KiSystemService falls into KiFastCallEntry, I use the word fall, because it does not call or jmp, KiFastCallEntry is at an an offset into KiSystemService, thus KiFastCallEntry is actually a part of the KiSystemService Function. If you are still confused, the above graph should help.
  • In user mode both Nt and Zw calls follow exactly the same path. Again, refer to the above graph if you are confused.
  • By hooking at a certain point in the flow chart, the rootkit is able to accept all calls to that point and from above it. In other words, by hooking at 3 the rootkit can intercept all successful calls made to 3, 2, and 1.
  • If while reading the kernel mode parts of this article, you are anywhere on the confused scale between "I'm not sure i get this" and "OMFGWTFBBQ", you probably need to read up on some windows kernel basics (especially driver/device stacks, I/O request packets and IRP major functions).

Conclusion

This is part 1 of a 2 part article, the next part will be coming soon and will explain how to detect (and possibly remove) the hooks explained in this article. If you have any questions or I've explained something badly, leave a comment and I'll amend the article.

Part 2: http://touchmymalware.blogspot.ru/2013/10/ring3-ring0-rootkit-hook-detection-22.html
↧

Ring3 / Ring0 Rootkit Hook Detection 2/2

October 8, 2013, 9:56 pm
$
0
0

Introduction

This article was actually planned to be posted the day after the first, however; I've not had much sleep the past few weeks, then I got sick, so it was very delayed. I'm pleased with how popular the previous article was, so in the future I plan to write more like this.  

In this part of the article i will be explaining some of the different ways to detect, bypass and remove hooks placed by malware.

Part 1

If you haven't read part 1 of this article, here it is: http://touchmymalware.blogspot.ru/2013/09/ring3-ring0-rootkit-hook-detection-12.html

IAT Hooks

Description
The Import Address Table (IAT) is a table of jumps "jmp dword ptr ds:[address]". Because functions in dlls change address, instead of calling a dll function directly, the application will make a call to the relevant jmp in its own jump table. When the application is executed the loader will place a pointer to each required dll function at the appropriate address in the IAT. 

I'm not sure this actually helps
if a rootkit were to inject itself inside the application and modify the addresses in the IAT, it would be able to receive control every time a target function is called. 

Bypass
Because the Export Address Table (EAT) of each dll remains intact, an application could easily bypass IAT hooks by just calling GetProcAddress to get the real address of each dll function. In order to prevent such a simple bypass, a rootkit would likely hook GetProcAddress/LdrGetProcedureAddress and use it to return fake addresses. These hooks can be bypassed by writing your own GetProcAddress implementation and using it to get the real function addresses.

Inline Hooks

Description
Inline hooking is a method of receiving control when a function is called, but before the function has done its job. The flow of execution is redirected by modifying the first few (usually 5) bytes of a target function. A standard way to do this is to overwrite the first 5 bytes of the function with a jump to malicious code, the malicious code can then read the function arguments and do whatever it needs. If the malicious code requires results from the original function (the one it hooked): it may call the function by executing the 5 bytes that were overwritten then jump 5 bytes into the original function, which will miss the malicious jump/call to avoid infinite recursion/redirection.

Example of an inline hook jumping to malicious code then executing the original function
Bypass / Detection (Ring 3)
In usermode inline hooks are usually place inside functions that are exported by a dll. The most accurate way to detect and bypass these hooks would be to compare each dll against the original code. First a program would need to get a list of each dll that is loaded, find the original file and read it, align and load the sections into memory then perform base relocation. Once the new copy of the dll is loaded into memory, the application can walk the export address table and compare each function vs that in the original dll. In order to bypass hooks, an application can then either replace the overwritten code using the code from the newly loaded dll, alternatively, it could resolve imports in the newly loaded dll and use it instead (be aware that some dlls will not work if more than 1 instance is loaded). 

This method of bypassing dll hooks practically involves writing your own implementation of LoadLibrary, it's really not for the beginners or faint-hearted. As much as I would like to post the code to do this, I won't, because it can (and will) be used by scriptkiddies to bypass usermode antivirus sandboxes or fight with other rootkits. 
(We can also use manual dll loading to detect / fix EAT hooks, I won't go into this in detail as EAT hooks are very uncommon). 

Bypass / Detection (Ring 0)
In kernel mode, inter-modular jumps are a lot more rare. Hooks in ntoskrnl can usually be detected by disassembling each instruction in each function, then looking for jumps or calls that point outside of ntoskrnl (into driver bodies, etc). It is also possible to use the same method explained for usermode hook detection: a driver could read each ntoskrnl module from disk, load it into memory and compare the instructions against the original. 

For inline hooks within drivers, scanning for jmp / call instructions that point outside of the driver body is much more likely to result in false positives, however, non-standard drivers that are the target of jumps / calls inside standard kernel drivers should raise a red flag. It is also possible to read drivers from disk. As drivers generally do not export many functions and IRP major function pointers are only initialized at runtime, it would probably be required that you compare the entire code section of the original and new driver. It is important to note that relative calls / jumps are susceptible to changes during relocation, this means that there will naturally be some differences between the original and new driver, however both relative calls / jumps should point to the same place. 


SSDT Hooks

Description
The System Serivce Dispatch Table (SSDT) is a table of pointers for various Zw/Nt functions, that are callable from usermode.  A malicious application can replace pointers in the SSDT with pointers to its own code.
Example call paths for Nt/Zw functions


Detection (Ring 0)
All pointers in the SSDT should point to code within ntoskrnl, if any pointer is pointing outside of ntsokrnl it is likely hooked. It's possible a rootkit could modify ntoskrnl.exe (or one of the related modules) in memory and slip some code into an empty space, in which case the pointer would still point to within ntoskrnl. As far as I'm aware, functions starting with "Zw" are intercepted by SSDT hooks, but those beginning with "Nt" are not, therefore an application should be able to detect SSDT hooks by comparing Nt* function addresses with the equivalent pointer in the SSDT.

Bypass
A simple way to bypass SSDT hooks would be by calling only Nt* functions instead of the Zw* equivalent. It is also possible to find the original SSDT by loading ntoskrnl.exe (this can be done easily with LoadLibraryEx in usermode) then finding the export "KeServiceDescriptorTable" and using it to calculate the offset of KiServiceTable within the disk image (Usermode applications can use NtQuerySystemInformation to get the kernel base address) , a kernel driver is required to replace the SSDT.

SYSENTER_EIP Hook

Description
SYSENTER_EIP points to the code to be executed when the SYSENTER instruction is used. Usermode applications use SYSENTER to transition into kernel mode and call a kernel function (Those beginning with Nt/Zw), usually it would point to KiFastCallEntry, but can be replaced in order to hook all usermode calls to kernel functions.

Detection / Bypass
SYSENTER_EIP hooking does not effect kernel mode drivers, and cannot be bypassed from usermode. In order to allow usermode applications to bypass this hook, a kernel driver must set SYSENTER_EIP to its original value (KiFastCallEntry), this can be done using the WRMSR instruction, however because KiFastCallEntry is not exported by ntoskrnl, getting the address could be tricky.

IRP Major Function Hook

Description
The driver object of each driver contains a table of 28 function pointer, these pointer are to be called by other drivers via IoCallDriver or alternative means, the pointers correspond to operations such as read/write (IRP_MJ_READ/IRP_MJ_WRITE). These pointers can easily be replace by another driver.

Detection
Generally all IRP major function pointers for a driver should point to code within the driver's address space, this is not always the case, but is a good start to identifying malicious drivers which have redirected the IRP major functions of legitimate drivers to their own code.

Bypass
Due to IRP major function pointers being initialized from withing the driver entry point (during runtime), it's not really possible to get the original values by reading the original driver from disk, there are also issues with loading a new copy of the driver due to collisions. The only way I can think of for bypassing these sorts of hooks would be calling the lower driver (Drivers are generally stacked and the top driver passes the data to the driver below and so on, if the lowest driver isn't hooked, an application could just send the request directly to the lowest driver).

Conclusion

I can't think of what to write for a conclusion, so here's a picture of a man being chased by a seal.

Seal of disapproval


↧

KINS Source Code Leaked

October 8, 2013, 11:42 pm
$
0
0

Much Ado About Nothing

Today the KINS source code was posted publicly after being sold to just about everyone and their dog. As expected it's just a Zeus modification containing code taken from various places (there is also evidence of the bootkit).


As you can see in this image, there is evidence of a bootkit present in the solution, however the files have been deleted by either the seller or someone who had the source before me. The files that have been deleted have the same names as those in the rovnix bootkit (from leaked carberp), I can say with 100% certainty that the bootkit being used by KINS is the one from the carberp leak.



This is some basic code to allow execution of 64-bit instructions from inside a 32-bit (wow64) process, I explained how this sort of thing is done in a previous blog post. The code was taken from rewolf's blog.



The above code makes use of the code taken from rewolf, it allows the bot to escape from the wow64 emulation layer. This code is useful because the wow64 layer prevents 32-bit processes from injecting into 64-bit processes on a 64-bit system, KINS makes use of this code to inject 64-bit processes from inside a 32-bit (wow64) process.


After a quick look, I wasn't able to find any evidence of a rootkit, however i did find this. The code keeps attempting to read the malware's file until it is successful, then keep rewriting the file and registry key every 2 seconds. You'll noticed the local variable "hFile" isn't actually used, so the check is useless.

That's all

I just highlighted the interesting stuff i found in the source, the rest of the code is taken from Zeus, however there is a lot of evidence in the solution that point to the presence of a bootkit and some exploits: ms10-073, ms10-092, and a spooler elevation (possibly MS10-061). You can also read xylitol's post about it here.

↧
↧

End of The Line for Solar Bot (Win32/Napolar)?

October 18, 2013, 8:31 am
$
0
0

Solar Bot

Solar Bot is a new type of usermode rootkit that created much hype by being "the first of it's kind". The rootkit is able to inject and hook both 32-bit and 64-bit processes, making it effective on 64-bit systems, which is uncommon for usermode rootkits. Solar bot makes uses of an inter-segment instructions to jump between 32 and 64-bit shellcode distributed with the bot (This is done by using jump/call instructions with the segment selector 0x33 to escape the wow64 emulation layer, I have posted a full explanation here). Although the method of executing 64-bit code within a 32-Bit(wow64) process is not new, it hasn't been seen being abused by malware before.

History

In the last half of 2012 a bot named RDDK (Remote Data Disclosure Kit) was being advertised on opensc.ws, this bot was nearly identical to the bot now know as Solar. The kit was much discussed, yet never actually got sold. A powerpoint released by the seller can be found here. 

A pre-sales discussion thread for RDDK

In early 2013 after the disappearance of opensc.ws, a new bot "Vector Bot" was introduced onto trojanforge.com, where most of the old opensc members took refuge. Due to the features being very similar (even down to the programming language), this bot was believe to be the completed version of RDDK. After many questions about the origin of Vector Bot, the seller claimed he purchased the RDDK project from a coder on opensc. About a month or so after Vector began being sold, the coder disappeared, leaving behind all the old customers with no support or updates. 

Around August/June, yet another bot with the same features appeared for sale on trojanforge. Despite much speculation that it was the return of the Vector Bot seller, after having ditched all his old customers, the bot made many sales and was much talked about. 

Source Sale

Shortly after trojanforge went offline, a sales thread for the source code was posted on exploit.in, a Russian forum, for an ambitious price of 100 bitcoins ($15,000 USD).


Sale of the source code usually signifies the end for a piece of malware. It is unlikely that the seller will continue sales, however, we might not see the source code leaked like with previous bots. Leaks usually occur with sources that are mass sold. Not only is the price incredibly high for malware of this kinds, but it is being sold in English on a Russian board, which usually results in significantly less sales. 
↧

Botnet Takedowns - fun and good publicity, nothing more

November 14, 2013, 7:21 pm
$
0
0

Takedowns

For the past year or so the Kelihos botnet has been in the news after constant attempts to take it down. recently the ZeroAccess botnet has also been subject to similar publicity, but what do these efforts actually achieve? Not much.

Damage

ZeroAccess and Kelihos are what i like to refer to as "non-aggressive botnets".  To me this simply means that the botnet takes a less aggressive stance toward generating income: usually by opting to mine bitcoins, perform click-fraud, or send spam, whilst renaming undetected to the user. These sorts of botnets tend to try and inconvenience the user as little as possible, so that they can hold onto the computer for as long as possible. If you compare this to the botnets that are encrypting users files and forcing them to buy them back, or stealing bank details and selling them to fraudsters, it suddenly looks a whole less damaging in the grand scheme of things.  

Resilience

Now I'm not sure i remember the last time i heard a bot master say: "oh no, the security experts have ransacked my botnet, I must pack up shop and apply for a job at McDonald." but I imagine it wasn't recently. The fact is, taking down these large botnets run by career cyber-criminals only causes minor financial setbacks and does little justice for the victims. As we saw with Kelihos, the developer's response was to come back each time with a new version of the bot which was more resistant to takedowns. Targeting the same botnets over and over is only likely to result in some new super-malware that is near impossible to sinkhole. Peer-to-peer botnets are usually very complex and a lot of work goes into them, why? To be sinkhole proof. When criminal groups are willing to put so much effort into avoiding sinkholing, it's likely that at most they will change tactics, but never walk away. 

Conclusion

The main motivator in taking down these high profile botnets appears to be publicity. I salute the security researchers that are doing this, but I think when anti-virus companies are pouring time and money into taking down botnets that are not causing extensive harm to the user, the efforts are misguided. I'd like to see more efforts go into dealing with the ransomware operations that seem to be growing in popularity, dealing with the botnets that are supplying cardshops with fresh credit cards, or just taking antivirus software to the next level. 




↧

MtGox Nearly Breaks Bitcoin...Again

November 19, 2013, 10:02 pm
$
0
0

Previous Incident 

In April 2013 large trading volume caused the MtGox trading engine to begin lagging. As soon as the trading engine lag started to build, traders panic sold due to the increasing risk of loss from trading blind. Of course the panic selling just added to the trading volume, thus adding to the lag (which reached 2h on peak). At the end of it all, when the lag died down, we were left with scenes of destruction and broke dreams.

What does the Gox say? Probably nothing with this much lag.


Today

At about 4:25 UCT an extremely large market sell order of about 4,000 bitcoin was placed, this caused the price to drop nearly $100 USD in under 2 minutes. The MtGox trading engine began to lag as the 4,000 bitcoin order hit all the corresponding buy orders as the price fell. According to MtGox, protection had been put in since the April 2013 crash, this protection canceled and rolled back all of the trades during the lag period, however, this somehow caused the engine to go into a loop where the sell order would be executed then rolled back then executed again, until stopped by MtGox.

"<@MagicalTux> very large sell order matching too many buy orders, causing the security system to stop the trade and rollback anything that was caused by it"

The initial sell order beginning


A view of the loop as plotted on the chart after the lag was gone

Current State

Although the MtGox lag did initially drag down the price on all other exchanges, it has since settled, although the market appears to still be in a downward trends. It's unsure if the gigantic sell order was neglectful or a deliberate attempt to cause panic, it's also not sure what happened to that order in the end, if it was ever processed or remains rolled back. 
Some facts are still unclear and i will update if any more information comes out. 
↧
Search

Portable Executable Injection For Beginners

November 21, 2013, 5:46 am
$
0
0

Process Injection

Process injection is an age old technique used by malware for 3 main reasons: Running without a process, placing user-mode hooks for a rootkit or formgrabber, and  bypassing antivirus / firewalls by injecting whitelisted processes. The most common method of process injection is DLL Injection, which is popular due to how easy it is. A program can simply drop a DLL to the disk and then use "CreateRemoteThread" to call "LoadLibrary" in the target process, the loader will then take care of the rest. PE Injection is generally favored over DLL Injection by malware, because it does not require dropping any files to the disk.

Portable Executable Basics

When running in memory most, but not all, portable executables make use of 2 structures we need to know about: IAT (Import Address Table), and Reloc (Base Relocation Table). I will briefly explain their purpose, without going into unnecessary detail. 

Import Address Table
When a DLL is loaded into memory it is not guaranteed to be loaded at the same address every time, to deal with this: the application makes use of an Import Address Table. The IAT simply allows for the addresses of DLL functions to be set by the PE loader, without having to modify the code of the application. It does this by having all calls to dll functions point to a jump in the processes's own jump table, the IAT then allows the address the jumps targets to easily be found and changed by the PE loader. 

Base Relocation Table
As with DLLs, it is also possible that the application itself is not loaded at the same address every time. For the most part this isn't a problem because the application uses relative addressing, however because absolute addresses will need to be changed if the process base address changes, whenever an absolute address is used, it must be easily located. The Base Relocation Table is a table of pointers to every absolute address used in the code. During process initialization, if the process is not being loaded at its base address, the PE loader will modify all the absolute addresses to work with the new base address.  

Portable Executable Injection

The Import Address Table and Reloc Table remain in memory once the process initialization is finished, this makes for a very easy way to inject a process. With the ability to be loaded at any base address and use DLLs at any address, the process can simply get its current base address and image size from the PE header, and copy itself to any region of memory in almost any process. Here is the entire procedure broken down.
  1. Get the current images base address and size (usually from the PE header).
  2. Allocate enough memory for the image inside the processes own address space (VirtualAlloc).
  3. Have the process copy its own image into the locally allocated memory (memcpy).
  4. Allocate memory large enough to fit the image in the target process (VirtualAllocEx).
  5. Calculate the offset of the reloc table for the image that was copied into the local memory.
  6. Iterate the reloc table of the local image and modify all absolute addresses to work at the address returned by VirtualAllocEx.
  7. Copy the local image into the memory region allocated in the target process (WriteProcessMemory).
  8. Calculate the remote address of the function to be executed in the remote process by subtracting the address of the function in the current process by the base address of the current process, then adding it to the address of the allocated memory in the target process.
  9. Create a new thread with the start address set to the remote address of the function (CreateRemoteThread).
  10. In some cases once the image is executed in the remote process, it may have to fix its own IAT so that it can call functions imported from DLLs, however; DLLs are usually at the same address in all processes, so this wouldn't be necessary. 

Identifying Injection

It is usually fairly easy to identify an executable that is attempting to inject into another. There are a few telltale signs to look for. The below tips are just guidelines and can lead to false positives, they also cannot be relied on to identify 100% of all injecting malware. 
  • A processes allocating memory inside another process (NtAllocateVirtualMemory, VirtualAllocEx, NtMapViewOfSection), especially if the memory is allocated with the PAGE_EXECUTE flag.
  • A process setting the PAGE_EXECUTE flag of a memory region in another process (NtProtectVirtualMemory, VirtualProtectEx).
  • A process creating a thread in another process (NtCreateThread(Ex), RtlCreateUserThread, CreateRemoteThread), especially if the thread points to code within a memory region, which was also allocated by the same process.
  • A process appending code to shared sections.


Extra

I will likely extend this article at a later date, possibly even add it to a series of articles about all the different injection methods. I'll also read over the article when I'm less tired and correct any stupid mistakes.
↧
↧

Selfish Mining - How to make Yourself Broke

November 23, 2013, 7:25 am
$
0
0

Selfish Mining

Selfish Mining in short is theoretical concept in which a malicious pool of miners could gain a better income by deliberately forking the blockchain. If a mining pool were to not immediately broadcast blocks, but instead add them to their own private chain, when the private chain becomes longer than the current chain; the malicious pool can publish their longer chain directly after a legitimate pool finds a block, causing the network to orphan the legitimate pool's block and give the reward to the malicious pool. By operating in such a way: every time the malicious pool orphans blocks mined by legitimate pools, the effort of the legitimate miners is wasted and they get no reward. In theory this could cause legitimate miners to jump ship into the malicious pool, giving the malicious pool more power, thus giving them a better ability to orphan other pools blocks. Eventually the malicious pool will be able to combine orphaning other pool's blocks + hashing power, in order to execute the 51% attack with less than 51% of the bitcoin network's hashing power. Full explanation here.

The Problem

As most people know, bitcoin has no intrinsic value and is entirely based on supply an demand. Traders make up the majority of bitcoin holder and as seen in the April 2013 crash, they are willing to liquidate their coins at the first sight of bad news. As soon as the selfish mining attack was noticed (easily noticed by the same pool repeatedly orphaning other pool's blocks), traders would begin to liquidate their coins, causing the value to drop. For the same reason the selfish mining attack could work (greed) other traders would see the value drop and also dash  to cash out. Before long there's a gigantic snowball of people liquidating their coins to the point where bitcoin is nearly worthless.

Most miners are also bitcoin investors. Due to the ever rising price per a coin, miners prefer to keep their coins as they increase in value with age. In the long run it is far more profitable to mine normally and keep hold of coins, than to mine maliciously and risk diminishing their value. Although this does not prevent the selfish mining attack, it makes it far less likely for non malicious miners to join a malicious pool, thus it would likely require the selfish pool to have a much larger number of malicious miners, before they could cause enough losses to bring in legitimate miners. It's also likely the malicious pool would be identified and miners warned not to join it, I would also guess it would lead to distributed denial of service attacks against the malicious pool. 

Conclusion

I don't doubt that a pool could selfishly mine, however, I do doubt it would ever grow large enough to cause noticeable problems for other miners. I'm also sure the pool would never get big enough to preform any of the attacks outlined in the 51% attack explanation. These are some of my theoretical problems with this theoretical attack, though i do think the attack is an incredibly cool concept, I don't believe it could be as damaging as stated. 
↧

Formgrabbers for Beginners

November 26, 2013, 4:34 am
$
0
0

Introduction

For a long time malware has targeted web data such as site logins. A malicious application could intercept socket functions within a web browser and scan for HTTP headers in order to retrieve HTTP data, however as HTTPS (HTTP Secure) became more widespread, it caused a problem. HTTPS is built on top of the TLS/SSL cryptographic protocols and is designed to prevent MITM (man-in-the-middle) attacks, before the HTTP request is sent to the server it is encrypted using TLS/SSL, this means that any malware intercepting socket functions would receive encrypted data it could not read. The solution: Formgrabbers. 

Web Browser Basics

Web browsers are made up of different APIs, the ones we need to know about are HTTP, Crypto and Socket.

A simplified representation of a modern browser.
As illustrated by the above image, the HTTP API is layered on top of the Crypto and Socket APIs. The web browser can call a function in the HTTP API to send a HTTP(S) Request. The HTTP API will handle the request differently depending on if it's HTTP or HTTPS.

  • If the request is HTTP the HTP API will use the Socket API to send the request to the server.
  • If the request is HTTPS the HTTP API will use the Crypto API to encrypt the request with TLS/SSL then use the Socket API to send it.
In the case of Internet Explorer, the HTTP API would be WinInet, the Crypto API would be Secure32 and the Socket API would be Winsock. 

A malicious application could intercept the Socket API to retrieve HTTP data, then intercept the Crypto API to retrieve HTTPS data before it is encrypted, but that would require intercepting at least 2 function in the browser, on top of that: different browsers use different APIs so that would further complicate things.

Formgrabbers

Eventually malware developers worked out that they could locate and intercept the HTTP API directly, although this proves difficult in some browsers it offered benefits: Not only would the malware not have to intercept 2 different functions in 2 different APIs, but by intercepting the HTTP API, the malware would be able to receive only HTTP(S) data and not have to worry about other data the browser may send or encrypt.
In order to intercept the relevant function in the HTTP API, the formgrabber would use inline hooking to: redirect the function to one within the formgrabber that would check and log the data, then transfer execution flow back to the relevant HTTP API function to complete the request.

Normal browser HTTP request execution flow.

HTTP request execution flow with a formgrabber installed.

↧

Infamous Skynet Botnet Author Allegedly Arrested

December 5, 2013, 2:09 am
$
0
0
On the 4th of December the German Federal Criminal Police Office (BKA) issued a press release stating they had arrested two suspects for computer crimes, with the support of GSG 9 (A German special operations unit). The release detailed that the two suspect has reportedly modified, distributed and used existing malware as part of a botnet, which had been responsible for mining over 700,000 euros worth of bitcoins (which have now been confiscated). There was also evidence found of other crimes committed, such as: fraud and distribution of copyrighted pornographic material. The full press release is in German but can be read here.

Skynet is a botnet that uses a modified version of the Zeus banking trojan, communicates using the IRC protocol (through TOR), and primarily mines bitcoins as well as harvesting banking information. The botnet is thought to be one of the first to use a TOR hidden service for a command and control server in order to evade sinkholing. The author gained a large amount of media publicity in late 2012 due to his usual openness about his illegal activities, mainly on twitter and reddit (in the form of an "Ask Me Anything" thread).

Although it cannot be confirmed that the pair arrested were those behind the Skynet botnet, the author hasn't tweeted since the alleged arrest and multiple sources who have worked closely with him have confirmed he was arrested. The story syncs up with the skynet author's operations such as selling banking information, mining bitcoin, using modified malware, and running a porn site.

A day prior to the alleged arrest the author appeared to be working on upgrading the Skynet malware to use a modified version of the leaked carberp bootkit, allowing the malware to start before antiviruses and run with kernel mode privileges. 




Update (12/5/13 2:09): 
According to researchers at botconf, GData have confirmed the arrest is that of the Skynet author.


Update (12/6/13 12:39):
A single tweet was posted from @skynetbnet's twitter account stating that the authorities had the wrong guy, no tweets have been made since. It would seem the tweet is an automated message or he requested a friend post it in the event of his arrest. Multiple people have in fact confirmed that the Skynet author has been arrested.






↧

Peer-to-Peer Botnets for Beginners

December 21, 2013, 8:17 pm
$
0
0
With all the hype about the ZeroAccess take-down, i decided it might be a nice idea to explain how peer to peer botnets work and how the are usually taken down.

Traditional Botnets

A basic example of a tradition botnet
With tradition botnets (Be it HTTP, IRC or some other protocol), the structure remains the same. The bots all connect to one or more servers through one or more domains. Although the network structure can differ from very basic to very complex, the botnet can easily be disabled with enough cooperation. 

seizing control of an active domain or sever associated with the botnet can usually be all that is needed in order to disband it, however if for some reason it isn't possible to send commands to the bots, a different approach is needed. Attempting to shut down the control sever is usually a waste of time as it would not take long for the botmaster to set up another and redirect the domain to it, which only leaves the option of going after the domain. 

A botnet that isn't run by beginners will likely use multiple domains, if a single domain is shut down, the bots will connect to the next. To take down such a botnet: it would be required for researchers to either suspend all domains associated with the botnet (in a time frame that doesn't allow the botmaster to update the bots with new domains), or to seize the domain the botnet is currently using and point it to a functional server (known as a sinkhole), designed to keep the bots away from the legitimate control server and out of the botmaster's reach. 


Peer to Peer

Peer to Peer (P2P) botnets try to solve the problem of security researchers and authorities targeting domains or servers, by creating a decentralized network. The idea of P2P is that all the bots connect & communicate with to each-other in order to remove the need for a centralized server, however it's not as straight forward as that.

CommandsIf bots are communicating with each-other, then the botmaster needs to make sure only he can command the bots, this is usually done using digital signing. Signing is performed by using asymmetric encryption, a special type of encryption that required two keys (public and private). if one key is used to encrypt a message, it can only be decrypted with the other key. If the botmaster keep one key secret (private key) and embed the other key in the bot (public key), he can use his key to encrypt commands and then the bots can decrypt them using the public key: without the botmaster's private key, no one can encrypt the commands.

Network Infrastructure
Figure 1
Most people's idea of a peer to peer botnet is similar to Figure 1, the bots all connect to each-other via IP address, forwarding commands to each-other, removing the need for a central server or domain, this representation however is incorrect. 

Computers that are behind NAT, Firewalls, or use a proxy server to access the internet: cannot accept incoming connection, but can make outgoing connection. This is a bit of a problem as it would prevent the majority of bots being connected to by other bots. In traditional botnets, this obviously isn't a problem as the bots connect to the server, so a peer to peer network still requires servers in a way. 

Figure 2
Bots that are capable of accepting incoming connections (not behind Proxy / NAT / Firewall) act as servers (usually referred to as nodes or peers), the bots that are not capable of accepting connections (usually referred to as workers) will then connect to one or more nodes in order to receive commands (Figure 2). Although the nodes are technically servers, they are used in a way that prevents take down, that is: the workers are distributed between many nodes, allowing them to shift to another node if one is taken down. P2P botnets only work if there are enough nodes that it is impractical to take them all down, the bad news is because the nodes are legitimate computers, they can't simply be seized like a server would be. 

Each node maintains a list of IP addresses of other nodes which it shares with the workers, the workers then store the lists, allowing them to switch nodes if the current one were to die. At this stage the botnet would just be many small groups of bots connected to many different nodes, which would be impossible to command. For commands to circulate the entire network, either: The bots will connect to multiple nodes and pass any commands received to the other nodes; The nodes connect to other nodes and pass commands between themselves; or a combination of the two. 



Bootstrapping
In order for a bot to join the network: it would need the IP address of at least one node, this is where bootstrapping comes in. The bot is hard-coded with a list of bootstrap servers, which it connects to when it is first run on the infected computer. the job of a bootstrap server is to maintain a huge list of node IP addresses, providing new bots with a smaller list of node IPs (introducing it to the network). Generally bootstrap servers provide some sort of signing, which prevents them from being hijacked by security researchers and used to give new bots invalid node IPs. 

Obviously the bootstrap servers are a central points, like with traditional botnets, they could be taken down, however this isn't a huge issue. If all of the bootstrap servers were to be seized at once, it would not effect the bots that are already on the botnet, however it would prevent new infections from joining. The botmaster can simply cease infecting new systems until they can set up new bootstrap servers,this would be only a temporary hold back so it is fairly pointless to attack the bootstrap system. 

Dismantling the botnet

Attacking the bootstrap system only temporarily prevents new bots joining the network, digitally signed commands prevent anyone other than the botmaster commanding the bots, and there are far too many nodes to take down at once, so what can be done? 

Peer Poisoning
Nearly all peer to peer botnets is existence have a vulnerability in the peer sharing mechanism. As explained earlier, the nodes are required to maintain and share a list of other nodes with the workers, to distribute the workers among the vast number of nodes. It would be incredibly time consuming or even impossible for the botmaster to manually provide each node with a list of other nodes, so the nodes do it automatically. When a new bot is identified as being capable of accepting connections, the node it is connected to adds it to the node list and shares it with the other nodes.

So what if you were to introduce a malicious computer to the network, one that would be identified as capable of becoming a node, the from there you provided the workers and other nodes with a list of invalid ips? Probably not a lot. It's likely that the nodes would verify each new node IP address to make sure it's real, but with that in mind there's another way! 

Security researchers could introduce many malicious nodes to the network, but instead of providing workers and other nodes with false IP addresses, they would only share a list of other malicious nodes. With enough resources, the malicious nodes can become a significant part of the botnet and separate the workers from the legitimate nodes. By only issuing the IP addresses of other malicious nodes, it increases the chance that the workers will only be aware of malicious nodes and significantly decreases the chance of them rejoining the network. At a given date the malicious nodes can stop forwarding commands from legitimate nodes: leaving all the workers which are connected to malicious nodes unable to receive commands, and leaving the botmaster no time to react. Such an attack would be unlikely to separate all the workers from the network, but could cripple a significant part of the botnet. Malicious nodes can be left running to commandeer more bots and attempt to keep hold of any bots which may have stored IP addresses of legitimate nodes. 


↧
↧

2013 In Malware

January 2, 2014, 7:58 am
$
0
0
As an end of year article, I though it might be a nice idea to review some of the interesting (to me) malware related events of this year. There's no specific order to the list, but I'll try to include dates for all. 

Peak Botnet Crisis


In the past few years malware has evolve rapidly, we've seen rootkits move from user-mode to kernel-mode and even dominate 64-bit platforms with bootkits loading unsigned drivers. The malware world and fraud world were brought together by popular banking malware, such as Zeus, leading to a huge demand for banking malware and a financially driven malware arms-race. In the last quarter of 2012, something strange happened. All the key malware developers slowly started leaving, retiring, or ending up in jail. By early 2013 the $40,000 Carberp Trojan was just about the only professional malware still on sale, however once sales stopped fraudsters were left with nothing. 

Throughout 2013 there was a huge demand for banking malware but little was seen, from time to time sellers would pop up with simplistic Zeus modifications looking to make a quick buck, but nothing serious was sold during the year. This malware shortage gave security companies an opportunity to catch up, with the discontinued Zeus Trojan still leading the way, it wasn't difficult for anti-viruses to detect and prevent the methods it used. For most of this year botmasters have been fighting a losing battle to maintain large botnets using old and detected technologies, which probably lead to a drop in the average size of botnets. 

Bug Bounty Fever

Contrary to what fool like trojan7sec will try to tell you, 0-day exploits are rare on the blackhat scene (For those who don't know, 0-day exploits are exploits that are currently unknown to developers and therefore not patched). Due to their difficulty to find and develop, an 0-day exploit can sell for upwards of $2,000 depending on the nature of the exploit. 0-day exploits used for remote code execution (commonly used in exploit packs) will generally sell for upwards of $40,000.

If someone was trying to spread malware using an exploit pack, it's likely the exploit pack would be discovered and reported on by security researcher, which would inevitably lead to any 0-days being quickly patched. From the point of view of someone trying to create a botnet, it would be much more cost effective to buy a handful of recently patched exploits for a small price, rather than spend $40,000+ per an exploit. In most cases people don't update their browser and software weekly or even monthly, so even patched exploits are likely to still be un-patched on a huge amount of targets (this is the reason nearly all exploit packs in existence use already patched exploits). 

Bug bounties are nothing new, but this year google (and others) have continued raising the rewards for researchers submitting 0day exploits. With the bounty for some exploits way into the $100,000 range, there is less incentive for hackers to struggle selling exploits on the black market, when they can quickly, easily, and legally sell them to the companies developing the software. Bug bounties have created a whole new culture, as well as encourage a few other companies to create bug bounty programs of their own.

Carberp Leak 


Probably one of the biggest malware related news stories of the year: After a dispute between Carberp group members the Carberp source code (including bootkit) is mass sold on underground forums, this inevitably leads to a pyramid of resellers with lower and lower prices, until the code is eventually leaked and falls into the hands of the public (24th june). At the time the leak seemed like a serious problem, but due to the advanced nature of the code it has been too complex for most malware developers to make use of, resulting in very few Trojans incorporating the bootkit. Carberp still remains the most advanced commercial banking Trojan and the most advanced malware source code to ever be leaked. 

POS Malware Gobbles Cards

A new type of malware starts showing up around the world. Point of Sales (POS) malware is a special type of Trojan designed for POS systems such as shop checkouts, the malware resides on the system and logs card details whenever a shopper pays by card. Because POS systems are internet connected and can process hundreds of cards per a week, POS malware poses a real big risk to card users. Although the malware is still not hugely widespread, it's something that's likely to become more and more widespread across 2014. 

This isn't the first time fraudsters have started targeting centralized systems instead of individual home computers: During the past few years we've seen a rise in ATM skimmers, which are special hardware fitted to ATM devices in order to log card details on use. 

Paunch Gets Sucked Into Blackhole

On October the 7th news emerged that paunch, the create of the blackhole exploit pack, had been arrested in Russia. Although people remained skeptical, the arrest was confirmed almost 2 months later. 

Blackhole was the most widely used exploit kit on the market, it has even been used by huge cybercrime groups such as those behind Carberp, ZeroAccess and TDL. Paunch's arrest saw some criminals switching back to older spreading methods such as email spam, whilst others moved over to lesser known exploit kits. Paunch also maintained a second exploit kit known as "Cool EK", which was a $10,000 month pack that included newer exploits and sometimes even 0-days. 


ZeroAccess Raises White Flag

On December the 5th Microsoft coordinated an attack against 18 IP addresses used by the ZeroAccess botnet. The attack was another of Microsoft's "look at how powerful we are" publicity stunts, the targeted IP addresses were C&C servers associated with the click-fraud component and not the actual bot. Due to the fact the actual botnet is peer-to-peer the attack has little effect and cannot actually take down the network, however it did lead to the botmasters sending a command containing the text "WHITE FLAG" and ceasing click-fraud. It's important to note that the botnet is still alive and can send out new commands at any time, only it is not performing click-fraud anymore. 

Based on the amount of time, cooperation, and effort it takes to acquire warrants for all of the C&C servers, it would seem that someone has too much time on their hands. This isn't the first waste of time operation Microsoft has executed: In 2012 Microsoft filed a lawsuit against a bunch of aliases and email addresses in order to seize domains and servers associated with various Zeus botnets. It takes weeks to obtain a warrant and only a few minutes for a criminal to setup a new server or domain, time could be better spent. 

TM's 2013 Scoreboard

Most interesting malware of the year
Rovnix bootkit - Probably some of the most interesting code I've seen: Stores components outside of the filesystem to make them almost invisible, uses custom TCP/IP stack to bypass firewalls, modifies OS image in memory to load unsigned 64-bit drivers, and capable of starting before any antivirus. 

Most over-hyped malware of the year
Kins - both blackhats and whitehats alike spent months ranting about the amazing new banking Trojan known as kins, calling it "the new Zeus" and "a professional-grade banking Trojan". Of course it just turned out to be a Zeus modification with some other leaked code copy and pasted in. 

Best anti-malware effort of the year
the "Malware Must Die" group - Doing their best to help fight malware in their free time, with limited resources. They were a big part of the Kelihos take-down operation as well as other smaller operation. Keep up the good work!

Biggest lamer of the year
Trojan7sec - I'm not sure where to start. Claiming to be a security researcher whilst engaging in blackhat activities, attempting to post the personal information of real security researchers, pathological lying with claims of being a millionaire and ex-superhacker, misleading beginners with false information while trying to seem like an expert, insulting and trying to contradict people who do know what they're talking about, the list goes on. He wins lamer of the year by far and probably lamer of century too. 

Worst malware Of the year
Cryptolocker - Puts the mal back in malware, seems the common methods of monetizing computers were too mainstream for these guys, so they decided to make money by encrypting people's files then selling them back.






↧

The Centralization of Fraud

January 8, 2014, 1:53 pm
$
0
0
Everyone is aware of the dangers of credit/debit cards, right? You get infected with banking malware or you leave your wallet at the bar, next thing you know there are bills for things you don't remember purchasing showing up on your bank statement. Well there was once a time when that was all you had to worry about, but things are changing now. In movies it's often portrayed that a hacker just sits at a computer emptying bank accounts and getting infinitely richer, however this is not the case. Card fraud is a risky and complicated business: It's near impossible to systematically empty bank accounts or max out credit cards and for this reason, most botnets collecting card information don't actually use it.

Fraudsters are always looking for cards to use and botmasters generally just want money, as a result botnets involved in harvesting card details just sell them in bulk to marketplaces (known as card shops), which in turn sell them to fraudsters. Due to using cards being risky and difficult, fraudsters are not willing to pay a great deal per a card, which means neither are cardshops, so the botmasters are always looking to harvest as many cards as possible whilst spending as little as possible. As you can imagine, running a large botnet isn't cheap and 100,000 bots don't yield 100,000 cards, in fact it's likely much less. There's also another problem: no one wants to buy the same cards twice, so the botmasters are always needing to infect new computers. There has to be a cheaper way?

ATM Skimmers

Well the obvious solution would be to target devices that process multiple cards, rather than home computers which are usually tied to a single user, this has made ATMs a target.

An ATM skimmer is a device that is fitted to the face of an ATM and designed to blend in. A standard skimmer kit consists of a keypad or camera and a card reader. The camera is generally part of older ATM skimmers and is used for recording users typing their pin. Newer skimmers use a fake keypad which fits over the original, when someone pushes buttons on the fake keypad, it presses on the real keypad all whilst logging the pin number (Keypad is only required if fraudsters wish to withdraw money, they only need card details to make purchases with them). The card reader looks like a standard ATM card slot and will fit over the real one, as the card passes through it will capture and store the data from it.

For fraudsters, ATM skimmers are great way to capture hundreds of cards from a single machine, however there are some drawbacks. Skimmers either store the data internally or Bluetooth it to another device, either way the fraudster are likely to revisit the scene of the crime to retrieve the skimmer or to download the data via Bluetooth. If an ATM skimmer was identified, police could easily monitor the ATM and surrounding area for the crooks returning to collect the data. People involved with ATM skimming are far more likely to get caught than people running botnets (which could be why skimmers are less common), however I'd still give the card slot a good tug before putting your card into an ATM.

POS Trojans

POS (Point of Sales) Trojans are another way fraudsters can target card reading devices (but without some of the risks associated with ATM skimmers), It's quite possible POS Trojans will be one of the biggest malware threats of the next few years.

POS systems have all the features malware developers love: They run windows (usually XP or lower), don't have antiviruses, and connect to the internet; The only problem is they all run different POS software. Developers eventually realized that instead of targeting the POS software the same way banking bots target browsers, they could scan the RAM for certain data. The malware simply scans the memory of each process for signatures relating to track 1/track 2 data (the format in which most cards store information), when a signature is found the data is uploaded to the C&C server (dexter and alina are public examples of such malware, they are also known a RAM scrapers).

Fraudsters often install/enable remote access programs such as VNC or Remote Desktop on the POS systems, allowing them to update the malware without the risk of returning to the system. If you're a customer: It's impossible to know if a POS system is infected without using it (Insisting that the cashier gives you access to the system will likely earn you a mandatory all-expenses-paid vacation in a 6x8 cell). Even if you do use an infected system, it could be days/week/month before the card is used by fraudster, which makes tracking down infected systems all the more difficult. The only sure way to not get caught out by an infected POS system is to pay in cash: Alternatively, you could use a credit card instead of debit card as they're easier to get your money refunded in the case of fraud (or so I'm told). It is believed that point of sales malware was responsible for the 2013 Target breach.
↧
Search

Malware - A One Night Stand

January 12, 2014, 11:51 pm
$
0
0
Last night i had this idea that ransomware and other "stab you in the face then steal your wallet" types of malware are likely a result of the antivirus industry becoming better at dealing with malware. It sounds like a crazy claim, but with a little explaining I think most people will see my point.


Botnets Are Hard Work

C&C IP and DNS blacklisting
Large public databases of IP addresses and domains associated with botnet control servers are updated frequently; Some firewalls use these databases to prevent malware connecting to the control servers, ISPs use them to suspend offending servers, and registrars to suspend offending domains. For a botmaster blacklisted IPs usually mean having to purchase more or even move server, if all the domains associated with the botnet are suspended the botmaster would lose total control of all the bots.

Monetizing
Generating an income can prove challenging: As soon as anti-virus blogs start monitoring a botnet, legitimate companies want nothing to do with it (this usually leads to shady dealings on underground forums).

Crypting
Currently it only takes a few days for a file to be detected by multiple anti-viruses, for files being distributed by known botnets, a sample can be detected by multiple anti-viruses in a few hours. Contrary to popular belief: nearly all usermode rootkits and most kernelmode rootkits cannot prevent anti-viruses removing their files (even if a reboot is required); once a sample is detected the botmaster has until the user or anti-virus reboots the computer to update the file with an undetected one, or the computer is released from their control. As a result of fast virus signature generation someone maintaining a large botnet would need to update all the bots with a non-detected exe at least once a day or risk losing bots. 

Takedowns
Recently botnet takedowns have been gaining popularity. Most of the large botnets take a severe beating for researchers and law enforcement (which costs the botnet owners time and money), even peer-to-peer botnets aren't safe due to the ever growing resource pool under the control of malware researchers. 

Ransomware

To an extent ransomware operations are similar to botnets: The malware spreads across various vectors (email, exploit packs, warez), requires the executable to be undetected by anti-viruses in order to improve chance of successful infection, and sometimes even phones home to a command and control server; however, ransomware works in a way that solves the problems highlighted with botnets.

Ransomware families such a winlockers do not require a C&C server, once a computer is infected the system is locked and the victim is forced to pay a set amount in order to receive  an unlock code. Cryptolockers encrypt a users files and required the user to buy a decryption key in order to regain access, once the files are encrypted there is no way to decrypt them without paying for the decryption key. Most cryptolockers store the decryption key on the C&C server, so taking it down only prevents victims from retrieving their files. 

Forcing a victim to pay an upfront ransom of between a few and a few hundred dollars could potentially make more money than the computer would have made in a whole year as part of a botnet. Once the victim has paid the computer is no use to the group running the scheme and it can be disinfected; this removes the need for keeping the computer up to date with undetected executables and trying hard to hide the presences of the malware. 

Conclusion

As you can see most ransomware works on a principal of infecting a victim, forcing them to hand over money, then getting off the computer as quickly as possible; This already hinders malware removal efforts, but if the ransomware has encrypted the files removal is entirely pointless (the victim will have no way to get their files back). 
As the anti-virus industry advances and botnets get harder and harder to maintain, i imagine it won't be uncommon to see much more dangerous and low maintenance malware that revolves around aggressively extorting money from victims as quickly as possible.



↧

Webinjects - The Basics

February 3, 2014, 6:22 pm
$
0
0

It's not uncommon for malware to use a technique known as formgrabbing; this is done by hooking browser functions responsible for encrypting and sending data to a webpage. By intercepting data before it is encrypted with SSL the malware can read the HTTP header and steal usernames and passwords from post data being sent to a target website.

The purpose of webinjects

Sometimes formgrabbing isn't enough: Most banks have security methods to combat man in the middle attacks. I'm just going to explain just one of the many security methods.

As well as the standard username and password, the user has a security pin number. During login the user is asked for their username, password, and 3 digits from their security pin: The digits required will be chosen at random (Eg. one time they might be asked for the 1st, 3rd, and 9th digit, another time they might be asked for the 2nd, 5th and 8th digit). The digits required change every login, the full security pin is never sent to the bank website, and there is no way to know which digit is which. In order to login to the bank account, the malware would need to be able to get the full security pin,which it can't get (or can it?).

Webinjects work in a similar way to a formgrabber, but instead they intercepting data being sent from the website to the browser; The data interception is done after the data is decrypted (SSL) but before the browser displays it, giving the malware the ability to modify webpages on the fly.

Webinjects In Action

In order to see exactly how modifying the webpage can retrieve the security pin from the earlier example, I've decided to try my hand at writing webinjects and infecting myself with Zeus (I've spent hours reversing banking malware but never got a chance to play with it). 

In order to try and save my self from being prosecuted by overzealous anti virus firms (*cough* Kaspersky *cough*), I'm going to be targeting a made up bank.


How the page should look

The data which is sent to the server via POST

Above is an example of our fictional bank site working properly, but in order to get the security pin the page has to be modified using webinjects. The webinjects will add an extra field asking for the full security pin, but the site says "You will never be asked to enter your full security pin", so the malware is going to remove that and replace it with a more convincing message.

Figure 1: The page once our Zeus webinjects are running


Figure 2: The data which is sent to the server via POST (with webinjects active)

Figure 3: Our webinjects and how they modify the page source

Figure 4: The log that gets sent to the Zeus C&C

As you may have noticed in figure 1 and 3 the full_secure_pin field was added by our injects and in figure 4 it is picked up by the formgrabber then sent to the C&C, however in figure 2 it has not sent to the bank website; This is because the formgrabber has the ability to remove post fields once it has logged them, so the field that was added by the webinjects is removed before the post data is sent to the bank, making the inject undetectable on the banks end. 

In order for an end user to know if they're infected with a banking Trojan which uses webinjects, the user needs to be looking out for them. If you notice fields, popups, requests or images that weren't there before: it's a good idea to check the page on another computer and get a friend to check it on theirs, if the page doesn't mach it's likely malware is modifying the page. 



↧
↧

The 0x33 Segment Selector (Heavens Gate)

February 14, 2014, 3:32 pm
$
0
0
Since I posted the article about malware using the 0x33 segment selector to execute 64-bit code in an 32-bit (WOW64) Process, a few people have asked me how the segment selector actually works deep down (a lot of people think it's software based). For those who haven't read the previous article, I suggest you read it fist: http://www.malwaretech.com/2013/06/rise-of-dual-architecture-usermode.html

Global Descriptor Table

The global descriptor table (GDT) is a structure used by x86 and x86_64 CPUs, the structure resides in memory, consists of multiple 8-byte descriptors, and is pointed to by the GDT register. Although GDT entries can be segment descriptors, call gates, task state segments, or LDT descriptors; we will focus only on segment descriptors as they are relevant to this article.

A segment descriptor uses a ridiculous layout for backwards compatibility reasons. There is a 4 byte segment base address which is stored at bytes 3,4,5 and 8; The segment limit is 2 and a half bytes and stored at bytes 1, 2 and half of 7; The descriptor flags are the other half of the 7th byte, and the Access flags are byte 6. That's probably pretty confusing, so I've made an example image.

(A segment descriptor) Fragmentation is cool now.

The only part of the segment descriptor that is relevant for this article is the "Flags" part, which is a total of 4 bits:
  1. Granularity (if 0, the segment limit is in 1 Byte blocks; if 1, the segment limit is in 4 Kilobyte blocks).
  2. D/B bit (If 0, the segment is 16-bit; if 1, the segment is 32-bit).
  3.  L Bit (If 0, the D/B bit is used; if 1, the segment is 64-bit and D/B bit must be 0).
  4. Doesn't appear to be used. 

The 4 bit "Flags" part of the segment descriptor.

Segmentation Basics

In real mode registers are 16-bit, which means that the CPU should only be able to address 216 (64 KB) of memory, that's not the case. The CPU has a special 20-bit register it uses for addresses which allows it to address 220 (1 MB), but how is that achieved? The CPU has a segment register which are also 16-bit, the segment register is multiplied by 16 (shifted left 4 bit) then added to the address in order to give a 20 bit address and allowing the whole 1 MB of memory to be accessed.

Protected mode segmentation is significantly different, the segment register is not actually a segment at all, it's a selector which is split up into 3 parts: Selector, TL (Descriptor Table), and RPL (Request Privilege Level):

  1. Segment Selector (13 bits) specifies which GDT/LDT descriptor to use, 0 for 1st, 1 for 2nd, etc.
  2. TL (1 bit) specifies which descriptor table should be used (0 for GDT, 1 for LDT).
  3. RPL (2 bits) specifies which CPU protection ring is currently being used (ring 1, 2, or 3). This is how the CPU keeps track of which privilege level the current operation is executing at. 


Segment selector format

Piecing Together

When you switch into 64-bit mode by doing a "CALL 0x33:Address" or "JMP 0x33:Address", you're not actually changing the code segment to 0x33, you're only changing the segment selector. The segment selector for 32-bit code is 0x23, so by changing the selector to 0x33, you're not modifying the TL or RPL, only changing the selector part from 4 to 6 (If you're wondering how the selectors are 4 and 6 not 0x23 and 0x33, it's because the low 3 bits are for the TL and RPL so 0x23 (00100011) is actually RPL = 3, TL = 0, Selector = 4 and 0x33 (00110011) is actually RPL = 3, TL = 0, Selector = 6).


A visual representation of the above.


So, changing the code segment register doesn't necessarily mean you're changing segment like it would in real mode, it totally depends on what the selector's corresponding descriptor says. As we know 0000000000100 is binary for 4 and 0000000000110 is binary for 6, so we need to pull GDT entries 4 and 6.




Here we can see the only difference between the entry for the 32-bit and 64-bit selector is the "Limit" and "Flags" field. The limit is easily explained: it's 0 for the 64-bit entry because there is no limit, and the 32-bit limit is 0xFFFFF because the granularity bit is set, making the limit (0xFFFFF * 4KB) AKA 4GB (the maximum addressable space using 32-bit registers). To understand the difference in the Flag's field, we'll have to view the individual bits. 




Here we can see the Granularity and D/B bits are set for entry 4, but for entry 6 they're not. Entry 6 also has the L bit set, why? The L bit means the CPU should be in 64-bit mode when this segment descriptor is being used, thus the D/B bit must be 0 as it is not in 16-bit or 32-bit mode. The granularity bit is 0 because the descriptor has no limit set as we showed earlier, so the limit granularity is irrelevant. So there you have it, both segment descriptors point to exactly the same address, the only difference is then when the 0x33 (64-bit) selector is set, the CPU will execute code in 64-bit mode. The selector is not magic and doesn't tell windows how to interpret the code, it's actually makes use of a CPU feature that allows the CPU to easily be switched between x86 and x64 mode using the GDT. 


If you're interested in how to dump GDT entries, you need to setup a a virtual machine and remotely debug it with windbg (you cant use local kernel debugger). Once you're connected remotely you can do "DG 0x23" to dump entry for segment selector 0x23 and it will output it in pretty text. If you want to get the raw bytes for the entry, you'll need to do "r gdtr" to get the address of the GDT from the GDT register, then you'll need to do "dq (GDT_Address+(0x8 * SELECTOR) L1" example: "dq (fffff80000b95000+(0x08*4)) L1".


↧

Zorenium - The Bot That Never Was

March 21, 2014, 12:43 am
$
0
0
I was first made aware of Zorenium bot at the start of November last year by a friend on twitter (R136a1). There were no actual sales threads, just a discussion in IRC and a pastebin post detailing some features (http://pastebin.com/Pp5xmtK7). After being sent a sample, I decided not to write an analysis due to the fact the code was incomplete, of very little interest, and low quality. The bot itself is all over virustotal and similar sites, so collecting samples was easy, however; there are no samples from any later than December 2013, which is when the author was said to have discontinued the bot (Samples Here). Looking at the samples we can tell 2 things: there are 2 different PDB paths which indicates 2 different computers (possibly 2 developers) and the bot is in very early stages of development. Code changes significantly from sample to sample, but all the samples only show very basic IRC and HTTP C&C code and incredibly limited features. The pastebin claims the bot has been worked on "night and day" since December 2012, which is something you should keep in mind. 

Some "evidence" of the bot's features - a screenshot showing some filenames and no code.


Yesterday some new pastebin posts were picked up and blogged about by Sensecy, before the article found its way onto the infamous threatpost blog (Original Blog Post, ThreatPost, Paste (December), Paste (March)). What's interesting about these posts is they imply the bot has gone from a barely functional HTTP/IRC bot, to a fully fledged peer-to-peer banking bot that runs on Android, IOS, Linux and Windows. If this bot is real, it would likely be the most advanced trojan ever, however; there's a few problems with some of the claims (in the pastebin and sensecy's article).

"Zorenium, a relative of Betabot" - Sensecy's Blog Post
When asked about betabot's relation to Zorenium, this was the betabot developers response:
<User> How is it related to BetaBot?
<Betabot Dev>  i have no idea
<Betabot Dev> it's not even real
<Betabot Dev> the guy never completed it, as he said himself

"we’ve also updated the rootkit, too a new version of the unreleased - TDL4 rootkit"
The TDL rootkit suddenly stopped updating a few years ago, which suggests the team are either retired or in jail. It's hard to believe that the team would resurface to sell an unreleased version of their bootkit to some guys who are selling a bot for £2000 GBP via pastebin.

"Zorenium will now run on Ios 5-7 Zorenium will also run on most debian platforms as well as the latest android ipad tablets"
It's physically impossible for malware to run on Linux, IOS and windows. If you were somehow able to compile all the code required for the 3 different operating systems into a single executable, how would it run? It might be possible in a cross-platform language like java, but Zorenium claims to be coded in C++ and compiled with Microsoft Visual Studio cl.exe (a windows C/C++ compiler).

"After alot of work, testing and money spent. We can now make the victims believe there SYSTEM is being shutdown on victim input, Thus means zorenium will throw fake images to make the user believe hes shutting down his machine. Zorenium will then shut down the screen to standby mode ( until the Poweron button is initialized ) Whilst the user thinks he or she is shutting down there machine, we can stop (Delay) the CPU Fan, and other fans, which will make a racket making the user believe his or her system is still running. remember this method is not 100% Guaranteed to overheat the victims computer, causing it to force shutdown"
Wat.
Not only does this make little sense, but I'm pretty sure there is no universal way to control PC fans. Some motherboards offer software to do it, but the software differs greatly.

"***THERE ARE STILL MORE I NEED TO ADD TO THIS DOCUMENTION, BUT WITH PLAYING CATCH ME IF YOU CAN WITH THE CYBER TEAM, ITS IMPOSSIBLE TO STAY IN ONE PLACE UPDATING THIS DOCUMENT*** STAY TUNED ***"
Some classic attention seeker action right here. Nothing says professional malware developer like running around the country fleeing authorities who are chasing you for a non-existent super bot.


-Update-
Sensecy has got back to me on my request, the bot is apparently sold on 1 forum and the seller has very little reputation, still not sure of the forum name though. 

Conclusion

Based on the fact that some of the features aren't even possible, none of the samples seen have any moderately advanced features, the only evidence of sales is a pastebin post, and no large security company has picked it up; I'm going to say the whole thing is fake. 

Obviously I will keep my eyes open for a samples of a new super bootkit banking bot using a private version of TDL4 and speading across windows, linux, android and iOS systems; let's see how long i can hold my breath. 

↧

Coding Malware for Fun and Not for Profit (Because that would be illegal)

April 10, 2014, 1:56 pm
$
0
0
A while ago some of you may remember me saying that I was so bored of there being no decent malware to reverse, that I might as well write some. Well, I decided to give it a go and I've spent some of my free time developing a Windows XP 32-bit bootkit. Now, before you get on the phone to your friendly neighborhood FBI agent, I'd like to make clear a few thing: The bootkit is written as a proof of concept, it would be very difficult to weaponize, and there is no weaponized version to fall into the hands of criminals.

For those of you who don't know, a bootkit is a type of rootkit that begins executing at boot time. By infecting the BIOS, Master Boot Record, Volume Boot Record or Initial Program Loader; Malware can begin execution early on in the operating system boot process, way before the OS is loaded. Most of the operating system's security measures are initialized later on by the kernel, so code running during the early boot stage has unrestricted access to the system, which can be used to subvert or even disable OS security features. The aim of most bootkits is to load a kernel driver that will allow the malicious code to continue executing once the OS is fully loaded; On 64-bit operating systems where kernel mode code signing is enforced, a bootkit can be used to patch out routines responsible for verifying driver signatures, allowing unsigned drivers to be loaded.

The reason i chose XP 32-bit is because the bootkit is actually designed as a payload for a much cooler proof-of-concept I'm working on, I didn't really have time to make a universal bootkit and I also didn't want to risk making the code to appealing to criminals for legal reasons (I believe an overzealous Kaspersky tried to prosecute fellow researcher Peter Kleissner for his "stoned" bootkit). Although the main proof-of-concept (that this bootkit serves as a payload for) is not complete, I thought it might be nice to release this part of it for people to study and to mark the death of XP.

The bootkit is a mix of 16-bit and 32-bit real mode and protected mode ASM, which is assembled using flat-assembler, The payload driver is a template driver written in C using Visual Studio 2012. Although targeted at XP Service Pack 3, the code appears to work fine on SP1 & SP2, but not SP0. I've not yet been able to test the kit on a physical machine but have done testing with VMware and Bochs.

The code is well commented, but I've also created a PDF based documentation that explains the XP boot process and the bootkit.

Files: http://www.mediafire.com/download/99ip8eyk65uqvkp/TinyXPB.rar
Git: https://github.com/MalwareTech/TinyXPB
PDF: http://www.scribd.com/doc/217533462/TinyXPB-Windows-XP-32-Bit-Bootkit






↧
Viewing all 139 articles
Browse latest View live
Search