Uncategorized

Entries with no category

  1. Rootkit Agent.adah Anatomy and Executables Carving via Cryptoanalytical Approach

    Today I'm going to expose how to perform the preliminar analysis of a Rootkit Application both via the classical Reverse Engineering approach and Crytpanalysis one.

    We will inspect a recent threat commonly detected as Rootkit Agent.adah, this rootkit is delivered in the usual form of executable (.exe) via Compromised or Malicious Websites.

    Usually the main executable is delivered in packed/compressed form and presents other executables embedded as resources, in other cases we can have blocks of encrypted data that will be decrypted on fly by the main executable.


    In the first step we are going to see how is structured the executable. CFF reveals us that the application is packed with UPX v3.0;

    Due to the nature of UPX, that is essentially a compressor, we will see a pattern almost constant, stabilized at high levels of entropy. Here a graph plot



    As should be evident, the internal structure and presence of embedded data is protected cause the constancy of the Entropy along the executable. In other words in this case the contribution from knowledge of entropy does not help us to have additional information. We have to perform more specific inspections, this time by using Floating Frequency Analysis.


    Let's spend some word about what mean Floating Frequency..

    The floating frequency of a document is a characteristic of its local information content at individual points in the document. The floating frequency specifies how many different characters are to be found in any given 64-character long segment of the document. The function considers sequences of text in the active window that are 64 characters long and counts how many different characters are to be found in this "window". The "window" is then shifted one character to the right and the calculation is repeated. This procedure results in a summary of the document in which it is possible to identify the places with high and low information density. A document of length n > 64 bytes has n-63 such index numbers in its characteristics.

    This is how work, implicitly should be clear enough how to interpret a Floating Frequency Graph,
    high values which deviate markedly from the background in an executable suggest that encrypted data or even cryptographic keys will be found in those places.

    Let's inspect the first graph:



    As you can see, with floating frequency we are now able to distinguish the PE Header that presents a low Differences Ratio, suddenly after the PE Header we can see UPX at work, plot is constant and uniform, near the end happens an interesting thing, a marked decrease of frequency that remains stable and uniform for a certain offset range, at the end of this isolated behaviour we register another abrupt decrease, this is the end of PE and obviously of the file.

    The isolated behaviour is truly interesting, the offset of this 'object' is placed in .rsrc section and presents a strong entropy due the evident density of Floating Freq. plot. A good compression algo introduces a significative increase of entropy, but if the block has already an high entropy this increase obviously cannot happen.We may think that the resource is compressed/encrypted. For example we could have another packed exectable.

    After this preliminary inspection we unpack the main malicious executable and inspect in the same way the unpacked one.

    Here the Entropy Plot of unpacked sample:



    As you can the, now the situation is different, emerges the evidence of PE Header, after a normal ammount of entropy, globally lower that the previous graph, a central drop caused by Zero Padding for PE Alignment, sucessively an increase long a defined amount of bytes (a block) and suddenly after an evident increase of entropy that reaches the RED Level. This mean that our previous observations on floating frequency plot was correct, here the 'object' that certainly is packed/compressed. Finally we have a classical slow down caused by the intrinsic structure of PE Format.

    Again let's perform the Floating Frequency inspection of the unpacked executable, here how changes the graph:



    Again Floating Frequency reveals us more details, or better (in this case) highlights better the structure of the whole executable plus the conformations of the two objects. If you pay attention to the first one, you can see that this corpse is truly similar to the global look of the unpacked executable, in other words we can state that the first object is effectively another merged executable!
    The second one is certainly a compressed object, the reason is clear just lookup the previous explaintions.

    Now let's see practically the whole body of our unpacked executable, from a classical Reverse Engineering point of view. We said that the two objects are placed into .rsrc section, let's look with Great CFF (I love this Tool ) if this is true.

    Bang! correct, the two merged resources are definitely two executables!
    The first one is a clean .sys, this is clear due to the presence of INIT in the PE Header.
    Also the second resource corresponds to our predictions, we have an UPX packed executable.

    Now should be trivial to carve these two executables, just locate the starting offset and by delimiting with Block Start/End function of CFF we obtain the executable size that added to the starting offset give us the final offset where to cut.

    The Block End corresponds obviously with the end of first/second resource.

    The .sys is the core file of our rootkit, I'll reverse it in a future post, the second executable, when unpacked become clear that is a DLL, if we take a look to some function name for exampe this:

    _NF_STATUS __cdecl nf_addRule(struct _NF_RULE *)

    became clear that this DLL acts as Network Filter by using NetFilterSDK ( http://netfiltersdk.com/ )

    But this is matter of future blog post.

    Hope you enjoyed this little paper

    Giuseppe 'Evilcry' Bonfa'

    Updated January 30th, 2010 at 09:17 by evilcry

    Categories
    Uncategorized
  2. RtlQueryProcessHeapInformation as Anti-Dbg Trick

    Hi,

    Directly derived from the previous Anti-Dbg Trick

    http://evilcodecave.wordpress.com/2009/04/14/rtlqueryprocessheapinformation-as-anti-dbg-trick/

    Have a nice read,
    Giuseppe 'Evilcry' Bonfa'
    Categories
    Uncategorized
  3. RtlQueryProcessDebugInformation as Anti-Dbg Trick

    The following paper will uncover some interesting undocumented functions relative to Windows Heap Enumeration.

    RtlCreateQueryDebugBuffer
    RtlQueryProcessDebugInformation
    RtlDestroyQueryDebugBuffer


    Here the prototypes for each function:

    Code:
    PDEBUG_BUFFER
    NTAPI
    RtlCreateQueryDebugBuffer(
    IN ULONG  Size,
    IN BOOLEAN  EventPair);
    Code:
    NTSTATUS
    NTAPI
    RtlQueryProcessDebugInformation(
    IN ULONG  ProcessId,
    IN ULONG  DebugInfoClassMask,
    IN OUT PDEBUG_BUFFER  DebugBuffer);

    Code:
    NTSTATUS
    NTAPI
    RtlDestroyQueryDebugBuffer(
    IN PDEBUG_BUFFER  DebugBuffer);
    Code:
    RtlCreateQueryDebugBuffer
    allocates buffer for storing heap data in case of success, it returns pointer to allocated debug buffer. Here the declaration of debug buffer:

    Code:
    typedef struct _DEBUG_BUFFER {
    HANDLE  SectionHandle;
    PVOID  SectionBase;
    PVOID  RemoteSectionBase;
    ULONG  SectionBaseDelta;
    HANDLE  EventPairHandle;
    ULONG  Unknown[2];
    HANDLE  RemoteThreadHandle;
    ULONG  InfoClassMask;
    ULONG  SizeOfInfo;
    ULONG  AllocatedSize;
    ULONG  SectionSize;
    PVOID  ModuleInformation;
    PVOID  BackTraceInformation;
    PVOID  HeapInformation;
    PVOID  LockInformation;
    PVOID  Reserved[8];
    } DEBUG_BUFFER, *PDEBUG_BUFFER;
    After the buffer allocation we can call the Heap Process Debug Information, we can call RtlQueryProcessDebugInformation to load all heap blocks of the process. This function loads entire heap nodes and corresponding heap blocks of the process. Debug Buffer contains the pointer to heap information structure at offset 0×38. First parameter of this heap structure is node count and after that it contains array of DEBUG_HEAP_INFORMATION structure which represent each heap node.

    Code:
    typedef struct _DEBUG_HEAP_INFORMATION
    {
    ULONG Base; // 0×00
    ULONG Flags; // 0×04
    USHORT Granularity; // 0×08
    USHORT Unknown; // 0×0A
    ULONG Allocated; // 0×0C
    ULONG Committed; // 0×10
    ULONG TagCount; // 0×14
    ULONG BlockCount; // 0×18
    ULONG Reserved[7]; // 0×1C
    PVOID Tags; // 0×38
    PVOID Blocks; // 0×3C Heap block pointer for this node.
    } DEBUG_HEAP_INFORMATION, *PDEBUG_HEAP_INFORMATION;
    As you should know a debugged process presents different flags respect a not debugged one, here the sample anti-dbg code:

    Code:
    #define WIN32_LEAN_AND_MEAN
    #include <stdio.h>
    #include <stdlib.h>
    #include <windows.h>
    #include <Psapi.h>
    #include “defs.h”
    
    #pragma comment(lib,”ntdll.lib”)
    #pragma comment(lib,”psapi.lib”)
    
    void QueryDbgBufferMethod(void)
    {
    PDEBUG_BUFFER buffer;
    NTSTATUS ntStatus;
    
    buffer = RtlCreateQueryDebugBuffer(0,FALSE);
    
    ntStatus = RtlQueryProcessDebugInformation(GetCurrentProcessId(),
    PDI_HEAPS|PDI_HEAP_BLOCKS,
    buffer);
    
    PDEBUG_HEAP_INFORMATION heapInfo = PDEBUG_HEAP_INFORMATION(PULONG(buffer->HeapInformation) + 1);
    
    if (heapInfo->Flags == 0×50000062)
    MessageBoxA(NULL,”Debugged”,”Warning”,MB_OK);
    else
    MessageBoxA(NULL,”Not Debugged”,”Warning”,MB_OK);
    
    RtlDestroyQueryDebugBuffer(buffer);
    }
    and here ‘defs.h

    Code:
    typedef LONG NTSTATUS;
    #define STATUS_SUCCESS ((NTSTATUS)0×00000000L)
    
    typedef struct _DEBUG_BUFFER {
    HANDLE SectionHandle;
    PVOID  SectionBase;
    PVOID  RemoteSectionBase;
    ULONG  SectionBaseDelta;
    HANDLE  EventPairHandle;
    ULONG  Unknown[2];
    HANDLE  RemoteThreadHandle;
    ULONG  InfoClassMask;
    ULONG  SizeOfInfo;
    ULONG  AllocatedSize;
    ULONG  SectionSize;
    PVOID  ModuleInformation;
    PVOID  BackTraceInformation;
    PVOID  HeapInformation;
    PVOID  LockInformation;
    PVOID  Reserved[8];
    } DEBUG_BUFFER, *PDEBUG_BUFFER;
    
    typedef struct _DEBUG_HEAP_INFORMATION
    {
    ULONG Base; // 0×00
    ULONG Flags; // 0×04
    USHORT Granularity; // 0×08
    USHORT Unknown; // 0×0A
    ULONG Allocated; // 0×0C
    ULONG Committed; // 0×10
    ULONG TagCount; // 0×14
    ULONG BlockCount; // 0×18
    ULONG Reserved[7]; // 0×1C
    PVOID Tags; // 0×38
    PVOID Blocks; // 0×3C
    } DEBUG_HEAP_INFORMATION, *PDEBUG_HEAP_INFORMATION;
    
    // RtlQueryProcessDebugInformation.DebugInfoClassMask constants
    #define PDI_MODULES                       0×01
    #define PDI_BACKTRACE                     0×02
    #define PDI_HEAPS                         0×04
    #define PDI_HEAP_TAGS                     0×08
    #define PDI_HEAP_BLOCKS                   0×10
    #define PDI_LOCKS                         0×20
    
    extern “C”
    __declspec(dllimport)
    NTSTATUS
    __stdcall
    RtlQueryProcessDebugInformation(
    IN ULONG  ProcessId,
    IN ULONG  DebugInfoClassMask,
    IN OUT PDEBUG_BUFFER  DebugBuffer);
    
    extern “C”
    __declspec(dllimport)
    PDEBUG_BUFFER
    __stdcall
    RtlCreateQueryDebugBuffer(
    IN ULONG  Size,
    IN BOOLEAN  EventPair);
    extern “C”
    __declspec(dllimport)
    NTSTATUS
    __stdcall
    RtlDestroyQueryDebugBuffer(
    IN PDEBUG_BUFFER  DebugBuffer);
    Regards,
    Giuseppe 'Evilcry' Bonfa'
    Categories
    Uncategorized
  4. Anti-Emulation Tricks

    Hi,

    Thanks to Gunther for ARTeam here we have some new Anti-Emulation open source functions, I’ve uploaded these on my OffensiveCOding section:

    here a quick list of the functions:

    Anti-KAV -> Call this one before WSAStartup(),so sockets wont be initialized.
    Anti-NOD32 -> sse1 instruction which nod32 cannot emulate.
    IsEmulator -> Timings Attack to Emulator Environement.
    IsCWSandBox -> Check if CreateProcess is hooked.
    IsAnubis -> Check whether it is running within Anubis.
    IsAnubis2 -> Check whether it is running within Anubis.
    IsNormanSandBox -> NormanSandBox Awareness.
    IsSunbeltSandBox -> Sunbelt Awareness.
    IsVirtualPC -> VirtualPC Awareness.
    IsVMware -> VMware Awareness.
    DetectVM -> Check whether it is running in VMWare, VirtualBox using registry.
    IsRegMonPresent -> Checking for RegMon by checking if the driver is loaded in memory and by searching for the window handle.

    Here the link:

    http://evilcry.netsons.org/OC0/code/EmulationAwareness.c

    See you to the next post..
    Categories
    Uncategorized
  5. Netsons killed my Website

    Hi,
    Netsons without any advice, suspended my account, now I don't have a web-space, if possible I'll try to find some Webspace.

    Regards,
    Giuseppe 'Evilcry' Bonfa'
    Categories
    Uncategorized
  6. Symbol Type Viewer 32Bit/64Bit v1.0.0.3

    Today I've finded a great tool, Symbol Type Viewer 32Bit/64Bit

    Symbol Type Viewer is a tool which makes it possible to easily
    visualize the types which can be defined in the symbols of the modules of the
    systems Microsoft Windows 32/64bit. Moreover, it makes it possible to convert
    these informations for the C language (.h) and the disassembler IDA of DataRescue
    (.idc).
    Link here

    Have a nice Day,
    Evilcry
    Categories
    Uncategorized