Supercharge your PowerShell defenses with Azure Sentinel, MITRE ATT&CK and Sigma

Jeff White from Palo Alto Networks recently wrote: PowerShell has continued to gain in popularity over the past few years as the framework continues to mature, so it’s no surprise we’re seeing it in more attacks. PowerShell offers attackers a wide range of capabilities natively on the system and with a quick look at the landscape of malicious PowerShell tools flooding out; you have a decent indicator of its growth.

Enter stage left — the PowerShell ‘-EncodedCommand’ parameter. This command intends to take complex strings that may otherwise cause issues for the command-line and wrap them up for PowerShell to execute. By masking the “malicious” part of your command from prying eyes you can avoid strings that may tip-off the defense.

How can we detect this? MITRE’s ATT&CK framework, Sigma’s open source project and Azure Sentinel can be teamed up to supercharge your defenses against these types of attacks. Let’s look at how we can do this.

Malicious PowerShell usage

Quite a number of droppers use these Base64 encoded PowerShell commands. For instance, they might try and abuse a Word document through a macro that will try and run cmd.exe which in turn runs PowerShell.exe which then parses an encoded command starting with a $.

Here’s a sample PowerShell script for you to try out encoding some sample command yourself:

$Text = ‘$cmd.exe’
$Bytes = [System.Text.Encoding]::Unicode.GetBytes($Text)
$EncodedText = [Convert]::ToBase64String($Bytes)
PRO TIP: My good friend and PowerShell MVP Ben Gelens pointed me at a Microsoft blog here that describes how PowerShell 5+ now supports the “Blue Team” better.


One of the first things you might ask yourself is how do I know which tactics, techniques and procedures (TTP’s) my adversaries are using? Unless you’ve been involved with research on bad actors and/or have been working on the “Red” (offensive) side yourself, you might not have all the information available on what people are using to attack you.

This is why the InfoSec community is about sharing information. Each might have a piece of the puzzle, and putting them together will provide all of us with the bigger picture, and will allow us to up our defenses in a bigger way. There are numerous conferences, blogs and other ways to get those learnings, but the MITRE ATT&CK project is one well worth mentioning.

What is MITRE? They describe themselves as:

“MITRE ATT&CK is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations.”

It’s a community project where many people with hands-on experience contribute. For instance Christiaan Beek, lead at McAfee, shares his learnings on TTP’s actively with MITRE.

The information MITRE ATT&CK provides can be consumed in many ways. They provide website which allows you to search the information, there is a ‘attack navigator’ that gives you an interactive way to work with the TTP’s, and there is a programmatic way (API) to retrieve the information as well.

If we query the ATT&CK framework, we find a TTP with number T1086 called “PowerShell”. MITRE provides information about the attack vector, which APT groups typically use it, and information on which phase of the ‘kill chain’ it maps to: Execution.

Two paragraphs in the TTP information MITRE provides could be of interest to you: Mitigation (how to defend against it) and Detection (monitoring, and possibly hunting):

“[..] If proper execution policy is set, adversaries will likely be able to define their own execution policy if they obtain administrator or system access, either through the Registry or at the command line. This change in policy on a system may be a way to detect malicious use of PowerShell. [..]”


So you’ve learned about the TTP’s that your adversaries might use. But we still need to ‘translate’ this approach to some real detection logic for our SIEM system. We need to provide the query the alert rules will use, and/or need to capture the relevant data to use for hunting later on.

Again, if you have been working on the offensive side, you might already have this information readily available. But most defenders will need to investigate the attack vector and come up with a plan as to which data sources to monitor, what to look for, and how the alerting logic would need to be configured.

And if you do find out what to monitor for, you’ll be most likely configuring it directly into your SIEM configuration and maybe not first write down the abstract of what you’re trying to achieve. (This is also the reason that replacing SIEM system is tough; no history of why something is configured there in the first place — but that’s a topic for another blog).

Florian Roth started a community project called Sigma which aims to provide a Generic Signature Format for SIEM systems. The detection logic is written in YAML format, and these .yml files can then be converted/translated into queries or rules for your specific SIEM systems (fi: Azure Sentinel, ArcSight, etc).

“Sigma is for log files what Snort is for network traffic and YARA is for files.”

The Sigma project has fully embraced MITRE’s ATT&CK framework as a way to classify the attack vector. If you look at the rule specification, in the tags section you’ll find fields called “attack.<number>” and “attack.<tactic>”. For our PowerShell TTP this would translate to attack.t1086 and attack.execution.

On Sigma’s Github repository you’ll find a folder called ‘Rules’ that contain quite a number of Sigma rules that Florian, other members of this project, or the broader community have developed and contributed. Under /rules/windows/powershell you’ll find a lot of rules for detecting PowerShell attack vectors.

PRO TIP: Interested in what MITRE ATT&CK coverage the public Sigma rules repo covers? Florian posted an overview here.

There are many ‘implementations’ of abusing PowerShell, but the one we were looking for is the one that uses Base64 encoded commands. The Sigma rule/definition for this one can be found here. A big thank you to Florian Roth and Markus Neis for the research and for sharing it to the Sigma repo.

PRO TIP: Want to get some technical details of Markus’ and Florian’s research? In the YAML file they point to this URL which contains some great information!

Azure Sentinel

Now that we have the Sigma rule, you will want to put that detection logic into your Cloud SIEM, Azure Sentinel. However, we need to take a final step: converting that YAML file into something that Azure Sentinel can read/process.

Guess what, Florian and his team also thought of that! It’s called SIGMAC as in Sigma Converter. In the /tools folder of the GitHub repo you will find it as a Python script. The scripts can output to a couple of common SIEM formats, fi: Splunk, Kibana, Arcsight and one that is called “ala”.

The target called ‘ala’ stands for Azure Log Analytics. This is the correct one, as Azure Sentinel uses Azure Log Analytics as its backend as you could read in my Azure Sentinel Design Considerations blog. Choosing ‘ala’ as the target in the Sigma Converter will produce the right KQL query as the result:

If you want to know more about Event ID 4688 which this signature uses, you can have a look on and get detailed information.

PRO TIP: Don’t forget to check the basics — am I collecting the events from the security eventlogs on my Windows servers? Is auditing properly enabled and configured in the OS? Are my Microsoft Monitoring Agents healthy and reporting into Azure Sentinel?

Putting it all together

Open up Azure Sentinel in the Azure portal and click on ‘Analytics’. Select ‘Add’ to create a new rule. Provide a name, description, severity, and paste in the KQL query. In the Alert Simulation section you’ll see if the query would have triggered.

PRO TIP: Make sure you select the right fields in the Entity Mapping section because you will need this later for Hunting. Then select the alert scheduling and alert suppression parameters, and Save the rule.

Now sit back and relax, and wait for the rule to kick in when a malicious Powershell command is run in your environment:

Because you’ve used the Entity Mapping, the alert maps back to the corresponding server, IP address, etcetera, which will assist you in Hunting. Not sure how to do this? Read my blog on using Jupyter and KQL to go Threat Hunting with Azure Sentinel.


Having a common open framework and taxonomy around TTP’s such as MITRE ATT&CK helps a great deal to organize our defense efforts. Combining that with a generic SIEM format to define the logic needed to detect these TTP’s such as SIGMA is really helpful. Having a community that actively contributes to these SIGMA rules is probably the best thing since sliced bread!

Downloading the alert rules and converting them to be used in Azure Sentinel has never been easier thanks to the community efforts of MITRE and SIGMA. Supercharge your cloud SIEM today!

A big shout out to Florian Roth (SIGMA), Jeff White (Powershell), Markus Neis (Alert Rule), Christiaan Beek (TTP),the people behind MITRE and many many others in the community who generously provide this to all of us!

— Maarten Goet, MVP & RD