Idea - Location information

[re-fox]

Description

An idea borrowed from some local yara rules.

Using location information within a capa rule could be used to restrict the scope (function/basic block) to a single location.

A pseudo-rule will explain better.

rule:
  meta:
    scope: basic block
  features:
    - and:
      - location: entry_point
      - or:
        - mnemonic: pusha
        - mnemonic: pushal
        - mnemonic: pushad

The following rule would be restricted to searching the scope (basic block) that exists at the entrypoint of the executable.

Possible location candidates

• PE Entrypoint
• Exported function offsets
• Section offsets?

A second example could resemble the following:

- and:
  - location: export(/ReflectiveLoader/)
  - api: VirtualAlloc
...
...

(This introduces an issue of having to match exported function names)

The logic could be more generic if the export name is not known

- and:
  - location: 1 of exported_function_addresses
  - api: VirtualAlloc
...
...

Which borrows (roughly) from the counting feature.

Implementation Considerations

Location data (for the locations I used in the above examples) all exist within the executable header. This is something that could be parsed via python and not a feature that has to be extracted by each engine.

This logic will break on shellcode, but that could be patched transparently so the rules will still work as intended.

if file_type == "shellcode":
    entry_point = 0
else:
    entry_point = pe.OPTIONAL_HEADER.AddressOfEntryPoint

Other

Another use case could be use/abuse of sideloaded DLL's. Where some DLL exported function does not match a known-good basic block or function signature.

This logic begins to drift closer to detection than sticking to Capa's core tenant of identifying binary capabilities. Slippery slope.

Drawbacks would be:

• Limited use
• Could introduce false negatives (if a rule is now overly restrictive)

[williballenthin]

I found myself nodding along as I read this proposal - you've explained it well and I think I can see how it could be implemented.

To support further discussion, especially around this feature's relative value, can you suggest a couple rules that might use this feature? and/or where you'd expect this to be useful?

[re-fox]

Thanks for the response and feedback.

The yara rule that I was drawing inspiration from was specifically looking for entrypoint oddities. It's a wide-net, low impact rule used to find potentially interesting samples.

Posting some of the yara-logic, and a rough capa translation.

Move imm to reg / indirect jump

mov eax, <location>
jmp eax

In yara, this would be a byte sequence resembling (only accounting for 32b, 64b would have leading 48|49 and the skip would be [1-8])

$mov_imm_call = (b8|b9|ba|bb|bc|bd|bc|bd|be|bf) [1-4]
ff (e0|e1|e2|e3|e4|e5|e6|e7) | 41 ff (e0|e1|e2|e3|e4|e5|e6|e7) 
----
at pe.entry_point

For capa, this would be a simple rule

rule:
  meta:
    scope: basic block
  features:
    - and:
      - location: entry_point
      - characteristic: indirect call
      - optional:
        - characteristic: cross section flow

Nops at EP

In yara (adjust uint for size)

uint32(pe.entry_point) == 0x90909090

In Capa this could be

rule:
  meta:
    scope: basic block
  features:
    - and:
      - location: entry_point
      - count(mnemonic(nop)): 4 or more

Obfuscated code flow -> jmp middle of next instruction

eb01        jmp 3
6860e80000  push 0xe860
...snip...

After the jump, the instruction pointer would now be at E8 or CALL

In yara

$middle_jump_call = {eb 01 ?? ?? e8 00}
---
at pe.entry_point

This doesn't translate well to a capa signature because the disassembler may be confused. @mr-tz has an issue #366 that is roughly similar. Some of the getPC obfuscation techniques involve confusing/bouncing the instruction pointer around a bit. I don't have a good solution here. Restricting the scope of the rule is one of the many steps to detecting the various getPC methods.

pusha/al/ad followed by call

pushal
call <location>

In yara

uint16(pe.entry_point) == 0xe860

In capa

rule:
  meta:
    scope: basic block
  features:
    - and:
      - location: entry_point
      - mnemonic: call
      - or:
        - mnemonic: pusha
        - mnemonic: pushal
        - mnemonic: pushad

Notes

None of these would be great capa rules, but restricting them location could make them usable or provide context. In most cases* Instructions like fnstenv (or other FPU) getPC tricks have more relevance within the context of the beginning of a program rather than just in any arbitrary function.

The location information may not provide much additional utility outside of these handful of use cases. That is one potential downside. Using Capa function signatures (pseudo-FLIRT implementation) and pairing with location could yield some interesting rules. I don't think I've fully realized those use cases yet.

[williballenthin]

In other threads, we've discussed the possibility of recognizing functions (usually by signature) and I presume the output of this would be the function's name. I wonder if this name information might also be used as a source to the location matcher (e.g. location: memcpy).

[williballenthin]

name discussion here: #414

[williballenthin]

implementing location: entry point would be straightforward.

what other locations should be supported?

[williballenthin]

• location: export (easy)
• location: tls callback (easy)
• location: ctor (not easy, but i've always wanted this)
• location: dtor (ditto)

[williballenthin]

• location: signature(memcpy) (relies on signature matching)

[re-fox]

I had not considered ctor/dtor. Good Catch.

A non-trivial, but potentially useful function would be thread start lpStartAddress (via CreateThread). This would become easier if signature matching is incorporated (also borrowing your idea from sequence matching).

[mr-tz]

• location: main (maybe just an alias for signature(main))