improve Heaven's Gate detection for computed selector variants

[akshat4703]

This PR improves detection for 64-bit execution via heavens gate to cover obfuscated variants where the 0x33 selector is computed at runtime instead of used as an immediate constant.

Fixes #1096.

Rule logic updates

1. Kept the existing strong pattern (call $+5 + add [esp], 5 + retf) and corrected the selector setup clause to properly allow either:

   • push 0x33, or
   • mov 0x33

2. Added a conservative secondary branch for the obfuscated selector construction pattern:

   • push 0x3
   • shl ... , 0x4
   • add ... , 0x3
   • push 0x0
   • retf

3. Added a reference to issue [64-bit execution via heavens gate] current rule misses obfuscated variants #1096 in meta.references.

Validation

• capafmt passed for the updated rule.
• lint --thorough -t "64-bit execution via heavens gate" passed.
• Rule still matches referenced example:
  • tests/data/79abd17391adc6251ecdc58d13d76baf.dll_
• Negative sanity check:
  • tests/data/mimikatz.exe_ -> no match for this rule.

[vee1e]

I feel this is too narrow of a fix. We could easily change the 0x33 constructor to be something like

• mov eax, 0x11
• imul eax, 3
• push eax

and the rule would be easily bypassed. I think the suggestions @devarjya27 suggested or detection for a retf after arithmetic operations would be better suited for generic matching. It would be helpful if we had a bunch of samples implementing this technique to refer to when improving the rule.

[akshat4703]

I feel this is too narrow of a fix. We could easily change the 0x33 constructor to be something like

• mov eax, 0x11
• imul eax, 3
• push eax

and the rule would be easily bypassed. I think the suggestions @devarjya27 suggested or detection for a retf after arithmetic operations would be better suited for generic matching. It would be helpful if we had a bunch of samples implementing this technique to refer to when improving the rule.

Thanks for the feedback!

You're right that the current rule is quite narrow and that the rule can be circumvented by making small changes in the construction of the constant. I'll look at the suggestions from @devarjya27 and see if I can create a more generic rule, perhaps by identifying the arithmetic construction of the constant and the usage of retf.

I'll also see if I can find other examples of this technique in use and validate the rule against that, so that we don't end up overfitting the rule against a single example. Thanks for the guidance!