You are browsing the archive for Batch Analysis.

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.

PE Section names – re-visited

December 15, 2016 in Batch Analysis, Malware Analysis

Update: This list has been last updated on 7th of January 2017

4 years back I published a list of PE section names; I recently thought of revisiting the list and as a result added a lot more entries.

This is the latest version of the list (note that there are duplicates, if treated as case-insensitive):

The packer/protector/tools section names/keywords

  • .aspack – Aspack packer
  • .adata – Aspack packer/Armadillo packer
  • ASPack – Aspack packer
  • .ASPack – ASPAck Protector
  • .boom – The Boomerang List Builder (config+exe xored with a single byte key 0x77)
  • .ccg – CCG Packer (Chinese Packer)
  • .charmve – Added by the PIN tool
  • BitArts – Crunch 2.0 Packer
  • DAStub – DAStub Dragon Armor protector
  • !EPack – Epack packer
  • FSG! – FSG packer (not a section name, but a good identifier)
  • .gentee – Gentee installer
  • kkrunchy – kkrunchy Packer
  • .mackt – ImpRec-created section
  • .MaskPE – MaskPE Packer
  • MEW – MEW packer
  • .MPRESS1 – Mpress Packer
  • .MPRESS2 – Mpress Packer
  • .neolite – Neolite Packer
  • .neolit – Neolite Packer
  • .nsp1 – NsPack packer
  • .nsp0 – NsPack packer
  • .nsp2 – NsPack packer
  • nsp1 – NsPack packer
  • nsp0 – NsPack packer
  • nsp2 – NsPack packer
  • .packed – RLPack Packer (first section)
  • pebundle – PEBundle Packer
  • PEBundle – PEBundle Packer
  • PEC2TO – PECompact packer
  • PECompact2 – PECompact packer (not a section name, but a good identifier)
  • PEC2 – PECompact packer
  • pec1 – PECompact packer
  • pec2 – PECompact packer
  • PEC2MO – PECompact packer
  • PELOCKnt – PELock Protector
  • .perplex – Perplex PE-Protector
  • PESHiELD – PEShield Packer
  • .petite – Petite Packer
  • .pinclie – Added by the PIN tool
  • ProCrypt – ProCrypt Packer
  • .RLPack – RLPack Packer (second section)
  • .rmnet – Ramnit virus marker
  • RCryptor – RPCrypt Packer
  • .RPCrypt – RPCrypt Packer
  • .seau – SeauSFX Packer
  • .sforce3 – StarForce Protection
  • .spack – Simple Pack (by bagie)
  • .svkp – SVKP packer
  • Themida – Themida Packer
  • .Themida – Themida Packer
  • .taz – Some version os PESpin
  • .tsuarch – TSULoader
  • .tsustub – TSULoader
  • .packed – Unknown Packer
  • PEPACK!! – Pepack
  • .Upack – Upack packer
  • .ByDwing – Upack Packer
  • UPX0 – UPX packer
  • UPX1 – UPX packer
  • UPX2 – UPX packer
  • UPX! – UPX packer
  • .UPX0 – UPX Packer
  • .UPX1 – UPX Packer
  • .UPX2 – UPX Packer
  • .vmp0 – VMProtect packer
  • .vmp1 – VMProtect packer
  • .vmp2 – VMProtect packer
  • VProtect – Vprotect Packer
  • .winapi – Added by API Override tool
  • WinLicen – WinLicense (Themida) Protector
  • _winzip_ – WinZip Self-Extractor
  • .WWPACK – WWPACK Packer
  • .yP – Y0da Protector
  • .y0da – Y0da Protector

List of popular section names

  • .00cfg – Control Flow Guard (CFG) section (added by newer versions of Visual Studio)
  • .arch – Alpha-architecture section
  • .autoload_text – cygwin/gcc; the Cygwin DLL uses a section to avoid copying certain data on fork.
  • .bindat – Binary data (also used by one of the downware installers based on LUA)
  • .bootdat – section that can be found inside Visual Studio files; contains palette entries
  • .bss – Uninitialized Data Section
  • .BSS – Uninitialized Data Section
  • .buildid – gcc/cygwin; Contains debug information (if overlaps with debug directory)
  • .CLR_UEF – .CLR Unhandled Exception Handler section; see https://github.com/dotnet/coreclr/blob/master/src/vm/excep.h
  • .code – Code Section
  • .cormeta – .CLR Metadata Section
  • .complua – Binary data, most likely compiled LUA (also used by one of the downware installers based on LUA)
  • .CRT – Initialized Data Section  (C RunTime)
  • .cygwin_dll_common – cygwin section containing flags representing Cygwin’s capabilities; refer to cygwin.sc and wincap.cc inside Cygwin run-time
  • .data – Data Section
  • .DATA – Data Section
  • .data1 – Data Section
  • .data2 – Data Section
  • .data3 – Data Section
  • .debug – Debug info Section
  • .debug$F – Debug info Section (Visual C++ version <7.0)
  • .debug$P – Debug info Section (Visual C++ debug information – precompiled information
  • .debug$S – Debug info Section (Visual C++ debug information – symbolic information)
  • .debug$T – Debug info Section (Visual C++ debug information – type information)
  • .drectve  – directive section (temporary, linker removes it after processing it; should not appear in a final PE image)
  • .didat – Delay Import Section
  • .didata – Delay Import Section
  • .edata – Export Data Section
  • .eh_fram – gcc/cygwin; Exception Handler Frame section
  • .export – Alternative Export Data Section
  • .fasm – FASM flat Section
  • .flat – FASM flat Section
  • .gfids – section added by new Visual Studio (14.0); purpose unknown
  • .giats – section added by new Visual Studio (14.0); purpose unknown
  • .gljmp – section added by new Visual Studio (14.0); purpose unknown
  • .glue_7t – ARMv7 core glue functions (thumb mode)
  • .glue_7 – ARMv7 core glue functions (32-bit ARM mode)
  • .idata – Initialized Data Section  (Borland)
  • .idlsym – IDL Attributes (registered SEH)
  • .impdata – Alternative Import data section
  • .itext – Code Section  (Borland)
  • .ndata – Nullsoft Installer section
  • .orpc – Code section inside rpcrt4.dll
  • .pdata – Exception Handling Functions Section (PDATA records)
  • .rdata – Read-only initialized Data Section  (MS and Borland)
  • .reloc – Relocations Section
  • .rodata – Read-only Data Section
  • .rsrc – Resource section
  • .sbss – GP-relative Uninitialized Data Section
  • .script – Section containing script
  • .shared – Shared section
  • .sdata – GP-relative Initialized Data Section
  • .srdata – GP-relative Read-only Data Section
  • .stab – Created by Haskell compiler (GHC)
  • .stabstr – Created by Haskell compiler (GHC)
  • .sxdata – Registered Exception Handlers Section
  • .text – Code Section
  • .text0 – Alternative Code Section
  • .text1 – Alternative Code Section
  • .text2 – Alternative Code Section
  • .text3 – Alternative Code Section
  • .textbss – Section used by incremental linking
  • .tls – Thread Local Storage Section
  • .tls$ – Thread Local Storage Section
  • .udata – Uninitialized Data Section
  • .vsdata – GP-relative Initialized Data
  • .xdata – Exception Information Section
  • .wixburn – Wix section; see https://github.com/wixtoolset/wix3/blob/develop/src/burn/stub/StubSection.cpp
  • BSS – Uninitialized Data Section  (Borland)
  • CODE – Code Section (Borland)
  • DATA – Data Section (Borland)
  • DGROUP – Legacy data group section
  • edata – Export Data Section
  • idata – Initialized Data Section  (C RunTime)
  • INIT – INIT section (drivers)
  • minATL – Section that can be found inside some ARM PE files; purpose unknown
  • PAGE – PAGE section (drivers)
  • rdata – Read-only Data Section
  • sdata – Initialized Data Section
  • shared – Shared section
  • Shared – Shared section
  • testdata – section containing test data (can be found inside Visual Studio files)
  • text – Alternative Code Section

Other section names

  • .text$<name> – Typically a temporary Code Section merged during building; <name> can be anything; the sections are sorted by name, and combined into a single .text section during the linking process
  • .data$<name> – as above, for .data section
  • .rdata$<name> – as above, for .rdata section
  • .rsrc$<name> – as above, for .rsrc section
  • /<number> – often found in Windows clones of *nix tools compiled with mingw/cygwin; these typically replace lengthy section names that are used under *nix; the compiler often preserves the section names in the debugging information (which is often attached to the file); most of PE dumpers can’t process the debug information and just shows the raw numeric section names; tools like IDA can process this information and shows us the real section names (f.ex. .autoload_text, .cygwin_dll_common);  examples below:
    • /4
    • /14
    • /19
    • /29
    • /41
    • /48
    • /55
    • /67
    • /78
    • /89
  • Related to the above, the sections used by mingw/cygwin are listed below (they can be found inside the cygwin.sc file in the source tarball).
    • .init
    • .text
    • .text$* (basically, .text$<name>)
    • .glue_7t
    • .glue_7
    • .fini
    • .gcc_exc
    • .gcc_except_table
    • .autoload_text
    • .data
    • .data2
    • .data$* (basically, .data$<name>)
    • .data_cygwin_nocopy
    • .rdata
    • .rdata$* (basically, .rdata$<name>)
    • .eh_frame
    • .pdata
    • .bss
    • COMMON
    • .edata
    • .debug$S
    • .debug$T
    • .debug$F
    • .drectve
    • .idata
    • .idata$2
    • .idata$3
    • .idata$4
    • .idata$5
    • .idata$6
    • .idata$7
    • .CRT
    • .endjunk
    • .cygwin_dll_common
    • .rsrc
    • .rsrc$* (basically, .rsrc$<name>)
    • .reloc
    • .stab
    • .stabstr
    • .debug_aranges
    • .debug_pubnames
    • .debug_info
    • .debug_abbrev
    • .debug_line
    • .debug_frame
    • .debug_str
    • .debug_loc
    • .debug_macinfo
    • .debug_ranges
    • .cygheap