FridaTrace++ – quick & dirty API monitor

May 31, 2020 in Batch Analysis, Frida, Malware Analysis, Sandboxing

In my two previous posts I described:

I’ve been experimenting with improving Frida Trace tool to enrich its output. Since the tool allows for rapid prototyping I decided to incorproate that SDK into it. After few weeks of endless coding that took barely 2-3h I came up with a first version of auto-generated handlers.

How does it work?

  • Install Python 3.7
  • Install Frida
  • Run automation (perl script) and build handlers for 16K APIs automagically
  • Place them in c:\python\__handlers__\
  • Run frida-tools

This is how it looks in practice:

  • c:\python\Scripts\frida-trace.exe c:\windows\notepad.exe -i *CreateFile*

You will notice that:

  • Instead of just an API name, we can now see a DLL name, actual API name, and all the arguments and their names as per SDK, and their values as well:
    • KernelBase.dll!CreateFileW (lpFileName=”C:\Windows\Fonts\staticcache.dat” (0x6483f8b310), dwDesiredAccess=GENERIC_READ (0x80000000), dwShareMode=0x5, lpSecurityAttributes=0x0, dwCreationDisposition=0xb6f000000003, dwFlagsAndAttributes=0x6400000000, hTemplateFile=0x0)
  • Return values are shown
    • RET = 0x<hex> /Kernel32.dll!CreateFileW/
  • For some arguments I added additional data enrichment
    • Extraction of file names passed to CreateFile* functions (also see below comment on all generic string arguments)
    • dwDesiredAccess is converted to a more readable flag dwDesiredAccess=GENERIC_READ (0x80000000) – this was a test of an idea, and it seem to work so can probably pretty quickly expand other attributes as well

If you look at the prototype files you will notice that they include a snapshot of SDK information which can help to manually develop code of a given API further:

The flag expansion idea I mention above can be best explained using the actual code – we build an array of masks, and walk through all of them, adding relevant strings as we walk through it (this code is not finished; and for some cases it will be just a direct comparison, not bit testing):

onEnter: function (log, args, state) {
GENERIC_READ      = 0x80000000
GENERIC_WRITE     = 0x40000000
GENERIC_EXECUTE   = 0x20000000
GENERIC_ALL       = 0x10000000

FILE_SHARE_READ   = 0x000000001
FILE_SHARE_WRITE  = 0x000000002
FILE_SHARE_DELETE = 0x000000004

masks =
[
  GENERIC_READ      , 'GENERIC_READ ',
  GENERIC_WRITE     , 'GENERIC_WRITE ',
  GENERIC_EXECUTE   , 'GENERIC_EXECUTE ',
  GENERIC_ALL       , 'GENERIC_ALL ',

  FILE_SHARE_READ   , 'FILE_SHARE_READ ',
  FILE_SHARE_WRITE  , 'FILE_SHARE_WRITE ',
  FILE_SHARE_DELETE , 'FILE_SHARE_DELETE '
]
dwDesiredAccess = ''

for (i = 0; i < masks.length/2; i++)
  {
    res = args[1] & masks[i*2]
    if ((res == masks[i*2]) || (res==-masks[i*2]))
     {
       if (dwDesiredAccess != '') { dwDesiredAccess = dwDesiredAccess + ' | ' }
       dwDesiredAccess = dwDesiredAccess + masks[i*2+1]
     }
  }
    log('Kernel32.dll!CreateFileW ('+
  'lpFileName='+'"' + args[0].readUtf16String() + '" (' + args[0] + ')'+', '+
  'dwDesiredAccess='+'' + dwDesiredAccess + '(' + args[1] + ')'+', '+
  'dwShareMode='+args[2]+', '+
  'lpSecurityAttributes='+args[3]+', '+
  'dwCreationDisposition='+args[4]+', '+
  'dwFlagsAndAttributes='+args[5]+', '+
  'hTemplateFile='+args[6]+')');
}

Quick and dirty stats on argument names across the whole SDK gave me this nice list:

  • dwFlags 1053
  • hdc 566
  • Flags 422
  • hWnd 352
  • hProcess 331
  • pszPath 227
  • hwnd 217
  • hKey 202
  • lpBuffer 201
  • error 187
  • lParam 175
  • engineHandle 174
  • riid 162
  • lpName 161
  • hFile 158
  • ServerIpAddress 157
  • lpFileName 156
  • Buffer 152

With that list I was able to identify a couple of arguments that are obvious strings – as a result I added argument expansion for them as well. We can see this in action here:

c:\python\Scripts\frida-trace.exe c:\windows\notepad.exe -i *strcmp*

When I ran the above command the first time I noticed that my handlers were missing msvcrt.dll prototypes for strcmp & _strcmpi so I added them manually copypasta-ing the prototypes for lstrcmp. This is obviously something that needs work as this particular library (and its versions) are very popular. Then we can think of VB programs, etc. – this just needs more time.

And speaking of time… time for a little bonus.

If you run this:

  • c:\python\Scripts\frida-trace.exe c:\windows\system32\cmd.exe -i *CreateFile* -i FindFirstFile*

you will run cmd.exe in a window of your current Frida Trace session.

So, as you type commands you can literally inspect which API calls are made to deliver given functionality. On the attached screen you can see how FindFirstFileExW API is executed to find files as per the wildcard ‘foo*’. After creating a file ‘foobar’, we can see how it is being accessed by CreateFileW.

This is literally the fastest API monitoring ever. I will be spending more time improving the handlers & when I am happy with the outcome I will post my automation script here.

A few more anti-sandbox tricks…

May 31, 2020 in Anti-*, Sandboxing

Update 2020-06-03

Added more details on MOVES, HABO and Jujubox

Old Post

Today I spotted an article comparing various sandboxes being posted on Twitter. I noticed many of sandboxes present on VirusTotal were not covered in that article so I reviewed a couple of reports and added these sandboxes to the list. While doing so, I picked up a few sandbox characteristics that seem to be fixed, and as such, can lead to programmatic identification of these solutions. In my opinion, sandboxes that don’t provide a randomized environment (different user, different system profile) are relatively easy to detect and sandbox creators need to take this into account to ensure their products remain stealthy. Also, providing screenshots is one of the easiest way to make profile available to attackers. I wonder if creating a fake desktop image could help here (window sized to the screen/workarea resolution and presenting a picture of a fake desktop)

Below are notes I took:

JujuBox

  • User: masked in reports as <USER>, but SID is not
  • SID: S-1-5-21-364843204-231886559-199882026-1001
  • OS version: not licensed and detectable via a trick I described a few days ago
  • Desktop includes Acrobat Reader, Firefox, Google Chrome, Open Office 4.1.6, Steam, accounting, eula, mydoc, mypresentation, OpenOffice, party, and stats — file extensions are not shown, but easy to guess
  • filename is a <SHA256 hash>.exe
  • Screen resolution seems to be low – 800x 600?
  • Only 4 icons on the taskbar


VenusEye

  • User: debug4fun

Yomi Hunter

  • User: j.yoroi

NSFOCUS POMA

  • OS: XP
  • User: sys
  • File: C:\Windows\Temp\sample\<md5>_<sha256>.exe

BitDam ATP

  • User: trans_iso_0

QiAnXin RedDrip

  • User: Administrator
  • System language: zh-CN

Tencent Habo

  • User: Administrator
  • SID: S-1-5-21-1482476501-1645522239-1417001333-500
  • File: sample.doc
  • Hostname: ANALYST<DIGIT>-<HEX>
  • OS: XP (refers to C:\Documents and Settings\Administrator)
  • System language: zh-CN
  • Directory present:
    • C:\DiskD
  • File: 996e.exe (this file name is so prevalent that it even raises questions on Reddit); wild speculation: I wonder if it comes from a Unicode character Ux996E (щео) which means ‘drink’; the reports attempt to remove information about the process name, but do so inefficiently as shown on the below screenshot
  • Other possible fingerprints:
    • OFFICE11 (C:\Program Files\Microsoft Office\OFFICE11\WINWORD.EXE)
    • Python
      • C:\Python\Python27
      • C:\Python\Python36

SecondWrite

  • User: Virtual
  • File: <hash> of the file and starts from %TEMP%\<hash>.exe

Dr.Web vxCube

  • Hides lots of information from the report, these guys know what they are doing (e.g. sample path is listed as <PATH_SAMPLE.EXE>)
  • OS: XP
  • Other possible fingerprints:
    • %CommonProgramFiles(x86)%\microsoft shared\vs7debug\mdm.exe
    • Office14 (%ProgramFiles%\microsoft office\office14)

Rising MOVES

  • User: Administrator
  • System language: zh-CN
  • Service present:
    • badrv
  • Kernel Driver present:
    • rs_badrv
  • Files present:
    • c:\analyse\drop_files.zip
    • c:\analyse\result.zip
    • C:\analyse\log.log
    • C:\analyse\analyzer.exe
    • c:/analyse/gen_report.py
    • C:\Program Files\Qemu-ga\gspawn-win32-helper.exe
  • Mutex:
    • ba_probe_event_memory_mutex

VirusTotal Cuckoofork

  • User: admin
  • Hostname: USER-PC
  • Other possible fingerprints:
    • starts sample from c:\ root directory
    • filename is a SHA256 hash

Lastline

  • User: Johnson, Olivia (randomized)
  • Other possible fingerprints:
    • Office14
      • C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE
    • Office16
      • C:\Program Files\Microsoft Office\Root\Office16\WINWORD.EXE

VMRay

  • User: nice to see proper randomization e.g. ‘aETAdzjz’
  • Other possible fingerprints:
    • Office16
      • C:\Program Files\Microsoft Office\Root\Office16\WINWORD.EXE

VirusTotal Box of Apples

  • User: user1

OS X Sandbox

  • Other possible fingerprints:
    • VMWare path mapped
      • Library/Filesystems/vmhgfs.fs

VirusTotal Androbox

  • n/a

VirusTotal Droidy

  • User: user