Add rules for detecting donut-related features

[Still34]

Summary

• This PR implements a few new rules for detecting a few features found in donut loader, a popular PE/assembly/script loader commonly used by malware.
• Adds
  • data-manipulation/encryption/chaskey/encrypt-data-using-chaskey
    • used for module encryption/decryption
  • data-manipulation/encryption/speck/encrypt-data-using-speck
    • used for hash calculations
  • load-code/dotnet/load-assembly-via-iassembly
    • used to load assembly in memory (this is currently a very loose rule; it shouldn't match false positive, but I haven't tested it on wide variety of samples yet - ideally this rule should be modified to look for known offsets related to CLR COM, but I could not get offset operand to work)
  • malware-family/donut-loader/load-shellcode-via-donut
    • uses all of the features above and matches partial functions that aren't unique enough to be created as their own rule
• Changes
  • data-manipulation/compression/decompress-data-using-aplib
    • adds number 31999 as some compilers may turn less than equal to less than, causing the condition to fail
• Closes detect donut loader #994

Notes

• Rules regarding PEB access currently still do not match this or other donut shellcode samples, even though it should. I could not figure out how to edit the existing rules accordingly.
• Additional rules may be able to be written that looks for known offsets to various COM calls, but I also could not get offset-based rules to work.

Sample

https://bazaar.abuse.ch/sample/d890c1c67d83f1131c065b5eb5f263cbf54559dbcdb4562c3bde3dc30d1a3205/

[mike-hunhoff]

Thanks @Still34 - this looks great so far. Please see my comments and open a PR at https://github.com/mandiant/capa-testfiles for the test file(s) referenced in these rules so we can get the lints passing.

[Still34]

I've been busy with other stuff this week and possibly for the next few days as well. I'll come back and address the comments before the month ends. Thanks!

[Still34]

I've tightened down the donut rule, and as for the basic block ones, I'm not entirely sure how I'd go about rewriting the rules to tighten the scope.

[Still34]

The IAssembly rule - ideally we'd match additional conditions like mov from certain offset to match the structure, but last I tried something like operand offset it would not match. As it stands, that rule is extremely weak, and I think it may match false positives. Some suggestions or help on that rule would be appreciated as well.

[mike-hunhoff]

The IAssembly rule - ideally we'd match additional conditions like mov from certain offset to match the structure, but last I tried something like operand offset it would not match. As it stands, that rule is extremely weak, and I think it may match false positives. Some suggestions or help on that rule would be appreciated as well.

What about bytes features, e.g. https://github.com/mandiant/capa-rules/blob/5fb8cee820ab87a11b7cc9a4c08a07ce982152a5/communication/http/initialize-iwebbrowser2.yml?

[Still34]

I'm more so hoping to match the structure offset. For example, this call to SafeArrayCreateVector

I was hoping to use the offset feature but I could not get it to match with something like offset: 0x70 or operand[1].offset: 0x70

[Still34]

I finally found out why the offset rule isn't working... The vivisect workspace loaded within IDA for some reason is not matching the offset rules whilst capa standalone does...?

i.e.,

      - or:
        - offset: 0x70
        - instruction:
          - mnemonic: mov
          - operand[1].offset: 0x70

is matching in standalone capa, but not within IDA