You are browsing the archive for Sandboxing.

Enter Sandbox – part 13: Sometimes it’s better to unfollow…

December 31, 2016 in Batch Analysis, Clustering, Sandboxing

The golden rule for many sandboxes is to attach the monitor to a every piece of executable code that is spawn by the analyzed sample. This approach has its obvious merits – many samples use lots of trickery and ‘seeing it all’ is a definite plus. It is also an unique selling point for some sandboxes to be able to ‘catch’ the most trickiest evasions that could otherwise potentially sneak-in under the radar of the monitor and do the evil thing while the sandbox would report nada…

I’d like to suggest a small, configurable optimization change to the sandbox behavior. One that should be relatively easy to implement for the most common use cases, and one that may be quite beneficial for readability and processing purposes.

Its name is ‘Unfollow’.

Let’s have a quick look at the below example:

Retrieves Module handle (via GetModuleHandleA): kernel32
Retrieves Procedure Address (via GetProcAddress): KERNEL32.dll, CreateProcessA
Retrieves Module handle (via GetModuleHandleA): kernel32
Retrieves Procedure Address (via GetProcAddress): KERNEL32.dll, GetModuleFileNameA
Loads Library (via LoadLibraryA): Shell32.dll
Retrieves Procedure Address (via GetProcAddress): SHELL32.dll, SHGetFolderPathA
Retrieves Module handle (via GetModuleHandleA): kernel32
Retrieves Procedure Address (via GetProcAddress): KERNEL32.dll, CreateProcessA
Creates Process (via CreateProcessA): , cmd=sc stop WinDefend, flags=
Retrieves Module handle (via GetModuleHandleA): kernel32
Retrieves Procedure Address (via GetProcAddress): KERNEL32.dll, CreateProcessA
Creates Process (via CreateProcessA): , cmd=sc config WinDefend start= disabled, flags=
Retrieves Module handle (via GetModuleHandleA): kernel32
Retrieves Procedure Address (via GetProcAddress): KERNEL32.dll, CreateProcessA
Creates Process (via CreateProcessA): , cmd=net stop msmpsvc, flags=

The story the log tells us is pretty clear – the sample is launching ‘sc’ and ‘net’ commands to kill/change the config of security services:

  • sc stop WinDefend
  • sc config WinDefend start= disabled
  • net stop msmpsvc

Look how clear the malicious behavior it is, and how easy it is to cherry-pick it from the logs, even in a textual format! Running a full-blown monitor over the spawn ‘utilities’ would be completely unnecessary… (unless of course, you want full report on IOCs, etc.).

In this particular case, my monitor just continues w/o following the programs the malware spawns i.e. recognizes their presence, but ‘unfollows’ them.

And what would happen if these were to be followed?

Let’s look at another example – the malware is executed, it connects to SCM, and first tries to Open, and if it doesn’t exist, Create the service called ‘vom’:

Connects to SCM database (via OpenSCMManagerA)
Opens a service (via OpenServiceA): vom
Creates Service (via CreateServiceA): vom

– at this moment the monitor would need to start monitoring the ‘services.exe’ that is responsible for service creation:

services.exe
...
Creates/Opens Registry Key: vom
Sets Registry Value (via NtSetValueKey): HKEY_LOCAL_MACHINE\SYSTEM\
     ControlSet001\Services\vom\Type, REG_DWORD, 1
Sets Registry Value (via NtSetValueKey): HKEY_LOCAL_MACHINE\SYSTEM\
     ControlSet001\Services\vom\Start, REG_DWORD, 0
Sets Registry Value (via NtSetValueKey): HKEY_LOCAL_MACHINE\SYSTEM\
     ControlSet001\Services\vom\ErrorControl, REG_DWORD, 1
Sets Registry Value (via NtSetValueKey): HKEY_LOCAL_MACHINE\SYSTEM\
     ControlSet001\Services\vom\ImagePath, REG_EXPAND_SZ, 
     system32\drivers\vom.sys
Sets Registry Value (via NtSetValueKey): HKEY_LOCAL_MACHINE\SYSTEM\
     ControlSet001\Services\vom\DisplayName, REG_SZ, vom
Creates/Opens Registry Key: Security
Sets Registry Value (via NtSetValueKey): HKEY_LOCAL_MACHINE\SYSTEM\
     ControlSet001\Services\vom\Security\Security, REG_BINARY,
...
and many many logs for all services affected

From the full-IOC report perspective – it makes sense, but if we talk about in-depth analysis where very specific high-level info is needed it actually adds a lot of noise to the report. We actually want to know what the sample does. Not how the service creation works (of course, it’s interesting, but not at this stage!).

Again, I emphasize it could be an optional setting – one that could enable individual analysts to speed up the log analysis by removing a lot of clutter from the final report, and perhaps enable the sandbox to ‘see’ more (as CPU cycles required by the ‘utility’ process monitoring and logging can be fully delegated to the main malware during – the typically short – session time). Of course, many modern reports can be ‘collapsed’ to hide the artifacts that are not that interesting + the process hierarchy is typically clearly shown on a graph, or a tree, but still – following processes is quite CPU-expensive and not always necessary.

Malware analysis using Wine

December 14, 2016 in Malware Analysis, Sandboxing

Wine is a free implementation of Windows on Unix. That’s what the Wine web site says. To a malware analyst though, Wine is a free analysis platform that can be leveraged to analyze Windows executables.

How so?

It’s all thanks to the various so-called debug channels that Wine offers. Some of these channels – when enabled – turn Wine into a fully-blown tracer, an API monitor, or a complete log madness that includes any possible messages from Wine.

I won’t cover here how to install Wine, but you should easily find a recipe online. Once installed, it’s ready for a few quick tests that will demonstrate its main monitoring features (from the malware analysts’ perspective):

  • Showing a list of loaded/unloaded modules (during run-time)
    • WINEDEBUG=+loaddll wine /mnt/<path>/notepad.exe

  • Showing list of API calls and their return values
    • WINEDEBUG=+relay wine /mnt/<path>/notepad.exe

  • Absolute tracing madness (yet still meaningful)
    • WINEDEBUG=+all wine /mnt/<path>/notepad.exe

A number of channels can be combined, f.ex. one can run the following command:

  • WINEDEBUG=+relay,+tid,+timestamp

to prepend the API log with a timestamp, and the TID (thread ID) of the current thread executing the API inside the process:

202729.726:0024:Call ntdll.RtlAllocateHeap(00110000,00000000,00000020) ret=7ed13224
202729.726:0024:Ret  ntdll.RtlAllocateHeap() retval=00118ac8 ret=7ed13224
202729.726:0024:Ret  rpcrt4.I_RpcGetBuffer() retval=00000000 ret=7ed57c45
202729.726:0024:Call rpcrt4.NdrServerContextNewMarshall(00b4e718,00119078,7ed55770,7ed612a4) ret=7ed57c81
202729.726:0024:Call ntdll.RtlFreeHeap(00110000,00000000,00118fc0) ret=7ed14071
202729.726:0024:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=7ed14071
202729.726:0024:Call ntdll.RtlReleaseResource(0011909c) ret=7ecfc83c
202729.726:0024:Ret  ntdll.RtlReleaseResource() retval=00000000 ret=7ecfc83c
202729.726:0024:Call ntdll.RtlDeleteResource(0011909c) ret=7ecfb4a7
202729.726:0024:Ret  ntdll.RtlDeleteResource() retval=00000000 ret=7ecfb4a7
202729.726:0024:Call ntdll.RtlFreeHeap(00110000,00000000,00119078) ret=7ecfb4bb
202729.726:0024:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=7ecfb4bb
202729.726:0024:Ret  rpcrt4.NdrServerContextNewMarshall() retval=001166a8 ret=7ed57c81
202729.726:0024:Call ntdll.RtlAllocateHeap(00110000,00000008,00000018) ret=7ed03c9c
202729.726:0024:Ret  ntdll.RtlAllocateHeap() retval=00118c20 ret=7ed03c9c
202729.726:0024:Call ntdll.RtlAllocateHeap(00110000,00000008,00000030) ret=7ed04c44
202729.731:0024:Ret  ntdll.RtlAllocateHeap() retval=00118fc0 ret=7ed04c44
202729.731:0024:Call KERNEL32.WriteFile(00000024,00118fc0,00000030,00b4e748,00000000) ret=7ed0cc8f
202729.731:0018:Ret  KERNEL32.ReadFile() retval=00000001 ret=7ec72d02
202729.731:0018:Call ntdll.RtlAllocateHeap(00110000,00000000,00000018) ret=7ec6be06
202729.731:0018:Ret  ntdll.RtlAllocateHeap() retval=0011b888 ret=7ec6be06

A few notes at the end:

  • Wine supports both 64- and 32- Portable Executables
  • There are 400+ different channels; I will lie if I say that I know what all of them trace
  • Obviously, running executables under Wine is a subject to various sandbox detections, including these I described in the past.
  • The analysis could be automated to produce a decent sandbox report; while it can’t compete with commercial sandboxes, it may be a a decent solution for in-house analysis, especially for small companies (and as an alternative, complementary sandbox)
  • If combined with other free solutions, may provide a secondary sandbox for differential analysis i.e. certain artifacts could be compared between 2 sessions (f.ex. one in cuckoo and one in Wine) and help in highlighting ‘randomness’ of some artifacts f.ex. mutex names, files created, etc.
  • Since it is running natively on Linux, lots of tools are available out of the box that may help in scripting and data processing
  • The source code is available and you can modify it to your purposes (f.ex. add automatic yara rule generation for specific artifacts, automatic URL extraction, etc.)
  • Last, but not least – it won’t work with some executables – it still has bugs & features that are not implemented yet

All in all, yet another tool that may sometimes come handy.