Update WMIC Discovery Rule + New System Discovery Rules For MacOS

[jstnk9]

Summary of the Pull Request

I have been doing some research through VT corpus identifying WMIC executions. I have identified that this rule is not working correctly on some occasions due to the use of upper or lower case on the command line and the order of the attributes :)

I haven't worked much with the "re" module. Please, if you think it is not necessary to do so, no problem, but I think that something similar even without using "re" could be interesting.

See this example: https://www.virustotal.com/gui/file/2de5f5fd4fc61f049f1227b65fd17b5fd480b79d3e55aec8c790717b39dd17a7/behavior

I have the following command line

C:\Windows\System32\wbem\WMIC.exe wmic os get Version

That command wasn't identified because the logic of the rule includes the following

- 'OS get Caption,OSArchitecture,Version'

In this case, is looking for a specific set of attributes followed Caption,OSArchitecture,Version. Sometimes threat actors just want to discover version for example.

---

Also added new MAC rules related to potential information discovery using utilities such as sw_vers and ioreg as well as a generic rule for detection base64 encoded content inside of images being decoded on the fly

Changelog

new: System Information Discovery Using Ioreg
new: System Information Discovery Using sw_vers
new: Potential Base64 Decoded From Images
new: System Information Discovery Via Wmic.EXE
update: Uncommon System Information Discovery Via Wmic.EXE - Updated logic to focus on more specific WMIC query sequence to increase the level and added a related rule to cover the missing gaps in d85ecdd7-b855-4e6e-af59-d9c78b5b861e

[nasbench]

Hey @jstnk9 thanks for this update.

A little bit of history regarding this rule. As discussed here, here and here the strict order was known to produce blindspots but was used in fear of FPs as while this is used for recon its wasn't going to warrant a medium if used in a non strict manner (without correlation at least).

What I suggest since you found this in the wild abuse. Is to keep your update as a low version rule and keep the old one with other variation that are more common now we have a little bit more data.

As a side note in sigma we assume the backend is case insensitive so a contains with a list like this

CommandLine|contains:
    - Example1
    - Example2
    - Example3
    ....

Would do the trick.

I will apply the update and you can check it out for additional comments or if you have feedback on this please let me know.

[jstnk9]

Thank you @nasbench for your comments! I will add the variation to the sigma rule that was already created.

On the other hand, I think that I have accidentally added three sigma rules for MacOS in this same pull request, I wanted to do it in a different one but everything went the same way xDD

[nasbench]

No worries man. Thanks for the updates, i'll check em in a bit

[jstnk9]

Let me know if you need any specific examples or samples. I have tried to be as descriptive as possible and add samples in the references that have the described behaviors :)

[nasbench]

Thanks once again for the submission @jstnk9

Made a couple of changes that i'll explain below.

• I split the WMIC rule as discussed. I refocused the old one on "specific" query sequence and added your version as a low level for now but has all variations that are interesting. So it should provide some neat results on VT (for hunting).
• I made some changes to the ioreg focused rule. I removed the grep and other flags to make it more generic. Imo this doesn't affect the quality as it still a medium one but now it'll find more stuff that perhaps use different shells or commands and flags (let me know if you disagree)
• I added some extra image extensions to the Potential Base64 Decoded From Images rule for increased coverage.

Cheers

[jstnk9]

Everything looks good for me man. Appreciate your time reviewing it. I have extra rules that I'll send next days/weeks.

Have a nice day dude!