Improving Post-Exploitation Behavior Detection on Windows with SigmaHQ

We have some great news for our Windows users!

We recently rolled out significant improvements for the Windows post-exploitation behavior detection, thanks to the import of 500+ Windows Process Creation rules from the SigmaHQ project into CrowdSec.

This integration strengthens the ability of the CrowdSec Security Engine to detect post-exploitation behavior, providing crucial insights into potential attacks on Windows systems.

What is the SigmaHQ project?

The SigmaHQ SIEM detection format is a globally recognized, community-driven framework that empowers security analysts to create and share rules for identifying malicious activity across diverse systems.

This SDL allows the community to create and share rules for various platforms. Those rules belong to three main categories:

• Generic Detection Rules: Focused on identifying behaviors or techniques that may be used by potential threat actors.
• Threat Hunting Rules: Broader in scope, providing starting points for analysts to hunt for suspicious or malicious activity.
• Emerging Threat Rules: Addressing specific, timely threats such as APT campaigns or zero-day vulnerabilities.

How we use SigmaHQ to improve Windows post-exploitation behavior detection

The first iteration of this feature focuses on Windows Process Creation from the Generic Detection Rules category. This feature has been on our roadmap for a long time, and it’s now possible thanks to some technical improvements in the scenarios and collection management introduced in Crowdsec Security Engine 1.6.4.

On the backend, we came up with a Sigma Pipeline and Backend that we intend to extend over time. It currently supports two categories:

• process_creation events on the Windows platform: We know how important post-exploitation is for Windows threat hunting.
• webserver category: We experimented a bit with it on honeypots, but we felt the results were not impactful enough for us to include it in some public collections as of now. We should follow up on those later on!

We intend to contribute this Pipeline and Backend directly to the SigmaHQ project if and when it’s relevant (it’s still early, and we are still figuring out a few things). But before that, we need to extend the categories of rules it supports to be useful.

Internally, the rules rely on SYSMON to track Process Creation. If you’re unfamiliar with this great tool, you can find information on how to install it and some great examples of configuration here.

Looking further, the top 5 MITRE ATT&CK categories represent more than 50% of the 500 Process Creation related rules, and are the following:

• Command and Scripting Interpreter: “Abuse command and script interpreters to execute commands, scripts, or binaries” — Massively related to patterns associated with specific hacking tools or techniques.
• System Binary Proxy Execution: “Bypass process and/or signature-based defenses by proxying execution of malicious content”: Avoiding detection
• OS Credential Dumping: “Dump credentials to obtain account login and credential material” — Detecting mimikatz and other password/hash dumping tools
• Impair Defenses: “Hinder or disable defensive mechanisms” — Detecting EDR/AV logging alteration.
• Masquerading: “Manipulate features of their artefacts to make them appear legitimate” — Evasion techniques

All those rules are strongly focused on post-exploitation behaviour — more “right of boom” than usual, since CrowdSec traditionally focuses on preemptive security approaches — but a great addition to the existing set of rules nonetheless.

Thanks to the SigmaHQ Project, we can significantly increase our ability to defend Windows systems, even when things go wrong, thanks to 500+ post-exploitation detection rules. And it looks great in the CrowdSec Console as well, with the relevant contextual information.

To wrap up

We loved the DSL and the community aspect of the project. However, the scenarios’ lack of testability and the rules’ heterogeneity regarding false positive risks and bypass are real challenges. 

We have always been adamant about tests when accepting contributions for scenarios and WAF rules, as we believe that testability and reproducibility of detection are crucial. Importing 500 rules at once without a proper testing framework was a challenge, but we believe it’s the price to pay to leverage the fantastic work the SigmaHQ community has done.

You will find detailed instructions on this Collection page. 

As always, feedback is welcome! Reach out to us on our Discord or Discourse and let us know what categories of SigmaHQ rules you want to see landing next!