dynamic: enable matching call arguments

[mike-hunhoff]

This has been discussed before (#771, #921) regarding static analysis but I do not believe we've revisited this since adding dynamic analysis. I think this is 100% worth implementing for dynamic analysis, now that we have easy access to call argument order, names, and values, to reduce FPs, e.g. mandiant/capa-rules#1023.

[PrajeetGuha]

Working on it

[williballenthin]

now that we have easy access to call argument order, names

We need to investigate and come up with a strategy for handling argument names. I recall that different sandboxes provide different names for arguments, derived from MSDN or other sources. So, how do we unify these?

What would these features look like?

For argument order, it might be like:

- call:
  - api: CreateFile
  - arg[0].string: "1.bat" = lpFileName

This thing is a bit of a hack, but it mirrors what we've done with instruction operands, like operand[0].number.

For argument names, it might be like:

- call:
  - api: CreateFile
  - lpFileName.string: "1.bat"

or even

- call:
  - api: CreateFile
  - lpFileName: "1.bat"

if we want to try to guess the type of the argument (???).

Though, as mentioned, this will take a little study around feasibility.

[williballenthin]

example of CAPE NtCreateFile. For this report, there are no calls to CreateFileA/W, only NtCreateFile, so maybe the hooking happens at that level.

and MSDN doc:

Note that CAPE has invented some argument names and the order/indices do not line up with MSDN.

[williballenthin]

example VMRay CreateFileW. no calls to NtCreateFile:

these arguments seem to be consistent with MSDN.

[williballenthin]

CAPE RegOpenKeyExW:

VMRay RegOpenKeyExW:

MSDN:

VMRay includes the information that I'd expect to see (from a low level perspective). CAPE will take some thinking...

[PrajeetGuha]

Unfortunately I don't think unification of different sandbox will be very difficult to achieve due to the variation in ways they work. Morever in future if new sandboxes are added which uses a complete different way to do the same, the solution may not scale well to the new ones.
The more feasible way might be to introduce something like -

sandbox: capa

and then implement the argument call functionality, but we may have to tradeoff some simplicity in developing the rule by this.

[mike-hunhoff]

Also, we should consider the benefits and trade offs of adding the ability to specify order when matching APIs in dynamic scope to reduce FPs.

e.g. I'm seeing spawn thread to RWX shellcode FPs that could be reduced if capa matched the ordering of API calls. In the following example the calls to CreateThread (1479) and NtCreateThreadEx (1478) occur before the call to NtAllocateVirtualMemory (1491). For this particiular technique we'd expect thread creation to occur after the RWX memory is allocated.

spawn thread to RWX shellcode (7 matches)
namespace  load-code/shellcode                                            
author     [email protected]                                      
scope      span of calls                                                  
mbc        Memory::Allocate Memory [C0007], Process::Create Thread [C0038]
span of calls @ vs_setup_bootstrapper.exe{pid:2560,tid:3304,calls:{1478,1479,1491}}
  and:
    match: allocate or change RWX memory
      or:
        call:
          and:
            number: 0x40 = PAGE_EXECUTE_READWRITE @ call:1491
              NtAllocateVirtualMemory(
                ProcessHandle=0xffffffff,
                BaseAddress=0x4a37000,
                RegionSize=0x1000,
                Protection=PAGE_EXECUTE_READWRITE,
                StackPivoted="no",
              ) -> 0x0
            or:
              match: allocate memory
                or:
                  api: NtAllocateVirtualMemory @ call:1491
                    NtAllocateVirtualMemory(
                      ProcessHandle=0xffffffff,
                      BaseAddress=0x4a37000,
                      RegionSize=0x1000,
                      Protection=PAGE_EXECUTE_READWRITE,
                      StackPivoted="no",
                    ) -> 0x0
    match: create thread
      or:
        and:
          os: windows
          or:
            api: CreateThread @ call:1479
              CreateThread(
                StartRoutine=0x721c4be0,
                ModuleName="clr.dll",
                Parameter=0x1571520,
                CreationFlags=0x4,
                ThreadId=0x16f8,
              ) -> 0x4c8
            api: NtCreateThreadEx @ call:1478
              NtCreateThreadEx(
                ThreadHandle=0x4c8,
                ProcessHandle=0xffffffff,
                StartAddress=0x721c4be0,
                Parameter=0x1571520,
                CreateFlags=0x1,
                ThreadId=0x16f8,
                ProcessId=0xa00,
                Module="clr.dll",
              ) -> 0x0

sample: https://www.virustotal.com/gui/file/0bbd04579d4de327121d361fe58d46e02d52c71fe025505e6b34d4f7e51b45e8/behavior