Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle API versions sandboxes vs. rules #1815

Closed
mr-tz opened this issue Oct 18, 2023 · 4 comments
Closed

Handle API versions sandboxes vs. rules #1815

mr-tz opened this issue Oct 18, 2023 · 4 comments
Labels
dynamic related to dynamic analysis flavor enhancement New feature or request

Comments

@mr-tz
Copy link
Collaborator

mr-tz commented Oct 18, 2023

I've noticed we run into issues since CAPE reports only list the api (like CreateFileA), however:

  • rules often include the DLL (which we won't get easily here)
  • use the generic name (like CreateFile [not A/W])

This is one way/part of handling this, maybe we can come up with a more generic way.

Originally posted by @mr-tz in #1809 (comment)

Statically, we always have all data. For dynamic we need to handle this differently.

@mr-tz mr-tz added enhancement New feature or request dynamic related to dynamic analysis flavor labels Oct 18, 2023
@mr-tz
Copy link
Collaborator Author

mr-tz commented Oct 19, 2023

CAPE sandbox output apis:

  • no DLL names included (but could be possible?)
  • A/W suffix for functions that have string arguments: e.g. RegOpenKeyExW / RegOpenKeyExA

See here for traced APIs: https://github.com/kevoreilly/CAPEv2/blob/3ac733c6d32fa0cdbe45f74920b21fa4c28203a3/lib/cuckoo/common/logtbl.py
Sidebar: We'll also have to double check which APIs (at which level, e.g. ntdll vs. kernel32) are traced and potentially update various rules.

capa rules apis:

  • DLL name often included
  • no rule with A/W suffix currently for functions that have string arguments: always use RegOpenKeyEx

So to make this work for dynamic analysis we'll have to:

@mr-tz
Copy link
Collaborator Author

mr-tz commented Oct 19, 2023

Question on "remove DLL names from rule apis (during rule loading)":

  1. do this only for dynamic matching - would require to pass down static/dynamic flavor into get_rules, static stays unaffected
  2. do this always (for both static and dynamic)

For the second option we could even reduce the overall extracted features. We loose some exactness but I see little practical impact.

@williballenthin
Copy link
Collaborator

agree that there's probably not a practical impact here. in theory there could be colliding API names, but i dont think i've ever seen this.

i like having the DLL names in the rules because it provides a hint to humans about where to find the routine. but i think we can very reasonably update the documentation to indicate that the DLL name is just used for documentation and not used during matching.

@mr-tz
Copy link
Collaborator Author

mr-tz commented Oct 20, 2023

closed via #1824

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dynamic related to dynamic analysis flavor enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants