Add rule to detect makecab staging of LOLBins

[alexegorov1]

Summary of the Pull Request

Adds a new Sigma rule for detecting makecab.exe usage to stage known LOLBins (regsvr32.exe, rundll32.exe, mshta.exe, certreq.exe). This behavior was previously uncovered by existing rules. The rule was field-tested with Chainsaw against real-world Sysmon logs and tuned for reliability: zero false positives in clean baselines, strong signal in known attack traces. YAML schema, field names, and detection logic follow current project conventions. Happy to adjust structure or placement based on team feedback.

Changelog

new: Suspicious Makecab Usage Against Known LOLBins

Example Log Event

Fixed Issues

SigmaHQ Rule Creation Conventions

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

[github-actions]

Welcome @alexegorov1 👋

It looks like this is your first pull request on the Sigma rules repository!

Please make sure to read the SigmaHQ conventions document to make sure your contribution is adhering to best practices and has all the necessary elements in place for a successful approval.

Thanks again, and welcome to the Sigma community! 😃

[nasbench]

Can you share a public reference or paste a log that you tested.

[alexegorov1]

Thanks for the note. Here are a few solid public references that directly support this detection logic:

1. https://attack.mitre.org/techniques/T1560/001/
   MITRE documents this technique (T1560.001 - Archive via Utility) as attackers using built-in tools like makecab.exe to compress files before exfiltration. The page explicitly names makecab.exe as an example of a native archiving tool abused for staging payloads or data. That’s exactly the use case this rule focuses on — detecting unusual makecab usage as part of attacker tooling.
2. https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-055a
   This official CISA alert (AA22-055A) covers the MuddyWater APT group. In the TTP section, it mentions use of makecab.exe to compress stolen data during real-world operations. This shows the tool isn’t just theoretical — it’s been used by adversaries for the same kind of activity this rule is trying to flag.
3. https://www.rapid7.com/blog/post/2021/03/23/defending-against-the-zero-day-analyzing-attacker-behavior-post-exploitation-of-microsoft-exchange/
   Rapid7 analyzed attacker behavior during live exploitation of Exchange servers. One of the behaviors observed was using makecab.exe to compress an lsass.dmp file — again, built-in compression as part of staging sensitive files for transfer. It is not LOLBins specifically, but this supports the broader pattern of malicious use of makecab.exe on high-value binaries.

Each of these sources shows how makecab.exe can be used in post-exploitation for staging — especially when paired with system binaries like regsvr32, mshta, or certreq. So this rule aims to detect: cases where known LOLBins are being packaged, which is almost never normal in real environments.

Let me know if anything else is needed — I can send logs if helpful, but wanted to keep it clean for now.

[alexegorov1]

Hi @nasbench — just checking in on this one. I’ve added the references you asked for and can share sample logs if that helps. Let me know if there’s anything else I should tweak to move the rule forward. Thanks!

[nasbench]

Closing this as it looks very much like AI slop :)

[alexegorov1]

Opinions aren't criteria. I provided public sources and offered logs. If Sigma has measurable acceptance criteria (events, datasets), publish them and I will meet them. Otherwise keep this closed - I've shipped the rule, tests, and sample events in my fork where the bar is technical