Features

Anubis is a tool for analyzing the behavior of Windows executables (by convention these files normally have an .exe extension) with special focus on the analysis of malware. To this end, the binary executable is run in an emulated environment and its (security-relevant) actions are monitored. This makes it the ideal tool for quickly getting an understanding of the purpose of an unknown binary.

Of course, we have compared Anubis to other existing analysis services to see how Anubis performs. Following is a short overview of our results.

Feature	Norman Sandbox	CWSandbox	Anubis
Analysis of Registry Activities
Analysis of File Activities
Analysis of Process Activities
Analysis of Windows Service Activities
Analysis of Network Activities
Native API aware Analysis
Unobtrusive Analysis
Complete View of the PC System	unknown

Analysis of Registry/File/Process/Windows Service/Network Activities

All tools are monitoring these basic interactions although the respective analysis-reports vary much in the quantity and quality of the presented information.

Native API aware Analysis

On Microsoft Windows platforms, the system call interface is called native API. It is mostly undocumented and not meant to be directly used by applications. Instead, applications are supposed to call functions of the documented Windows API. The Windows API is a large collection of user mode library routines,which in turn invoke native API functions when necessary. The idea is that the Windows API adds a layer of indirection to shield applications from changes and subtle complexities in the native API. In particular, the native API may change between different Windows versions and even between different service pack releases. On a Windows system,the native API is provided by the system file ntdll.dll. Malware authors sometimes use the native API directly to avoid DLL dependencies or to confuse the operating system simulations of virus scanners. For this reason, it is important not only to monitor the Windows API function calls of an application but also its native API function calls.

We have written a very small test program in order to test the different malware analysis programs.

//Small demo program that creates a file using the Windows Native API
int main(int argc, char *argv[])
{
    //Dynamically load ntdll.dll and find out the addresses of 
    //NtCreateFile and RtlInitUnicodeString
    HMODULE hMod= LoadLibrary("ntdll.dll");
    if (! hMod)
    {
        cerr << "Could not load ntdll.dll" << endl;
        exit(1);
    }

    NtCreateFile *pNtCreateFile;
    RtlInitUnicodeString *pRtlInitUnicodeString;
    pNtCreateFile= (NtCreateFile*) GetProcAddress(hMod, "NtCreateFile");
    pRtlInitUnicodeString= (RtlInitUnicodeString*) 
                           GetProcAddress(hMod, "RtlInitUnicodeString");

    //Prepare all arguments for the call to NtCreateFile
    IO_STATUS_BLOCK ioStatus;
    memset(&ioStatus, 0, sizeof(ioStatus));

    OBJECT_ATTRIBUTES object;
    memset(&object, 0, sizeof(object));
    object.Length= sizeof(object);
    object.Attributes= OBJ_CASE_INSENSITIVE;

    UNICODE_STRING fn;
    pRtlInitUnicodeString(&fn, L"\\??\\C:\\testfile.txt");
    object.ObjectName= &fn;

    //Finally, create the file C:\testfile.txt. 
    //If the file already exists, it is truncated.
    HANDLE out;
    NTSTATUS status;
    status= pNtCreateFile(&out, GENERIC_WRITE, &object, &ioStatus, 
        NULL, FILE_ATTRIBUTE_NORMAL, 0, FILE_CREATE, 0, NULL, 0);

    if (! NT_SUCCESS(status))
    {
        cerr << "Could not create file." << endl;
        exit(1);
    }
    else
        cerr << "Successfully created the file." << endl;


    return 1;
}

Get the complete source-code or the compiled executable.

Unobtrusive Analysis

It is essential that the runtime-behavior of an executable in the analysis-environment matches its behavior on a real world computer. And it is essential that the malware cannot (easily) detect the presence of the analysis environment. For example, several malware samples check for the presence of a known virtualizer such as VMWare and behave differently depending on the outcome of this check. This is because virtualizers are mostly used by computer virus analysts so that they can safely analyze the malware sample.
Again, we have written a small test-program that tests the three malware analysis programs for this ability. Our test program is based on Joanna Rutkowska redpill program that checks for the presence of VMWare.

void inside_vmware()
{
    printf("Inside VMWare.");
    fopen("C:\\inside_vmware.txt", "w");
}

void outside_vmware()
{
    printf("Outside VMWare.");
    fopen("C:\\outside_vmware.txt", "w");
}

int main(int argc, char* argv[])
{
    unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
    *((unsigned*)&rpill[3]) = (unsigned)m;
    ((void(*)())&rpill)();

    printf ("idt base: %#x\n", *((unsigned*)&m[2]));
    if (m[5]>0xd0) 
        inside_vmware();
    else 
        outside_vmware();

    return 0;
}

Get the complete source-code or the compiled executable.

Complete View of the PC System

This feature is a measurement for the extent of the analysis. Is the analysis confined to monitoring API calls or can the analysis see CPU register values and keep even track of memory accesses?
Currently, none of the three tested malware analysis tools (including our own) does more than monitoring (native) API calls. However, the next generation of malware analysis tools will certainly do more. Thus, this feature determines how extensible the current systems are and how well they are prepared for the future.

There are no tests programs that could detect this feature. Instead, we have relied upon the public available documentation of the respective analysis systems in order to determine the presence of this feature.

Last Modified: 2008-10-10