Added ordinal of ShellExec_RunDLL

[swachchhanda000]

Summary of the Pull Request

Adversaries have been observed leveraging the ordinal number of the ShellExec_RunDLL function in the shell32.dll library instead of explicitly using the function name (ShellExec_RunDLL). This technique bypasses this current detection, which rely solely on the function name, enabling execution of arbitrary system binaries such as cmd.exe or powershell.exe.

Changelog

new: Suspicious ShellExec_RunDLL Call Via Ordinal

Example Log Event

Screen.Recording.2024-11-16.at.7.03.25.PM.mov

Fixed Issues

SigmaHQ Rule Creation Conventions

• If your PR adds new rules, please consider following and applying these conventions

[frack113]

HI,
I was looking for malware references to add about the ordinal , I found that https://strontic.github.io/xcyclopedia/library/shell32.dll-65DA072F25DE83D9F83653E3FEA3644D.html
But get
ShellExec_RunDLL | 568 | Exported Function

[swachchhanda000]

HI, I was looking for malware references to add about the ordinal , I found that https://strontic.github.io/xcyclopedia/library/shell32.dll-65DA072F25DE83D9F83653E3FEA3644D.html But get ShellExec_RunDLL | 568 | Exported Function

@frack113 I also referred to the same link, but it didn't work as expected with the ordinal number 568 for ShellExec_RunDLL. It seems they got it wrong or something has changed. I will look at SHELL32.dll exported functions and their ordinal numbers
to verify it

[nasbench]

HI, I was looking for malware references to add about the ordinal , I found that https://strontic.github.io/xcyclopedia/library/shell32.dll-65DA072F25DE83D9F83653E3FEA3644D.html But get ShellExec_RunDLL | 568 | Exported Function

@frack113 I also referred to the same link, but it didn't work as expected with the ordinal number 568 for ShellExec_RunDLL. It seems they got it wrong or something has changed. I will look at SHELL32.dll exported functions and their ordinal numbers to verify it

Just FYI @frack113 @swachchhanda000 This is due to different versions of the DLL somewhere in Win11 the export ordinals changed

Just as a side note, you need to add all 3 variations because they achieve the same thing.

The only dangerous thing is the FP rate with cross version of windows. As long there isn't a field indicating which version of windows this is running on, there's gonna be false alerts. You could use the Imphash (if you wanna track them) as a side solution with each collection in their independent selection.

In my opinion just create a new hunting version of this that focuses on using ordinals and specify in details what I discussed here in the description

[swachchhanda000]

HI, I was looking for malware references to add about the ordinal , I found that https://strontic.github.io/xcyclopedia/library/shell32.dll-65DA072F25DE83D9F83653E3FEA3644D.html But get ShellExec_RunDLL | 568 | Exported Function

@frack113 I also referred to the same link, but it didn't work as expected with the ordinal number 568 for ShellExec_RunDLL. It seems they got it wrong or something has changed. I will look at SHELL32.dll exported functions and their ordinal numbers to verify it

Just FYI @frack113 @swachchhanda000 This is due to different versions of the DLL somewhere in Win11 the export ordinals changed

Just as a side note, you need to add all 3 variations because they achieve the same thing.

The only dangerous thing is the FP rate with cross version of windows. As long there isn't a field indicating which version of windows this is running on, there's gonna be false alerts. You could use the Imphash (if you wanna track them) as a side solution with each collection in their independent selection.

In my opinion just create a new hunting version of this that focuses on using ordinals and specify in details what I discussed here in the description

I think we can reduce false positives by being more specific. For example, we can include these indicators in the parentcommandline, ensuring it has spawned the child process. This means the ordinal number is effective; if it isn't, the rule won't trigger at all. To be even more precise, we can specify a rule to hunt for suspicious child processes, such as cmd.exe, powershell.exe, wscript.exe, and others.
what do you think @nasbench and @frack113 ?

[frack113]

As they can be many FP with the ordinal.
Why not make a derived from d87bd452-6da1-456e-8155-7dc988157b7d for the ordonal only ?

[swachchhanda000]

HI @frack113 , @nasbench ,
I have accommodated all the ordinals as suggested and made a derived rule

[frack113]

The detection logic looks good to me