Access Helix API with PowerShell

In this installment of the Tips and Insights series, Bryon Wolcott explains how to access the Helix API with PowerShell or other scripting languages to interact with Helix.

Hi my name is Brian Wolcott. I’m a Senior Security Analyst at FireEye. In this video I’m going to show how you can access the Helix API with PowerShell. This is an example of how you can use your favorite scripting language to interact with Helix. So today we’re going to use PowerShell in order to submit a git request against the alert’s namespace. We’re going to take the API key that we generated. We’re going to submit that as the x-FireEye-api-key field. The Content-Type does have to be set to application/json. So let’s submit this request and we’ll see what we get back. So we can see we get two fields replied. One is the meta field which tells us that there are 17,000 alerts but in this case it returned 30 because that’s the default limit. We can increase that and get all of them back if we want but well to start with 30 for now. And then we can see the alerts and this is where that information for each alert actually is. Let’s look at the first one and we’ll see what type of information replied back to us. This was all the information about the alert. You can see the message. This is the rule name that made the alert fire. You can see when the first event was. This specific identifier key. Specific distinguisher key from this alert. Let’s look at all of our alerts sorted by time and see which rule made them fire. So take all of our objects. We’ll sort them by update date and we’ll throw them into a table to show us the rule that hit and the time. Let’s go ahead and look at the first alert that came back and we’ll have a look and see what type of information it was getting to us. So in this case we can see the update date. So this is the last event in this alert and the time that it came into the system. We can see the message field which is the name of the rule that made this alert fire. Now if we go down to trigger ID this is the actual ID number of the alert which is pretty useful if you want to go back into Helix and explore the rule itself or maybe you need to tune the rules so you can find it easily that way. So we know some of the basic fields let’s go ahead to look at the 30 alerts that replied to us and we’ll have a nice little overview of what’s going on. This is a really fast overview of all the last 30 alerts that came in and which rule made them fire. Now you can really use this information anyway you want. We’ve seen people create their own custom dashboards. They throw it up in the SOC to show all the latest alerts that are coming out. It’s really handy information and how you can use the information in Helix to build on it and make it better if you need to. We only returned 30 alerts in this case but the power here is that you can return lots of data and then you can process it off line. So if you were to return 10,000 events your browser might not do very good with that because that’s going to consume a lot of memory. But if you were to take it into a command line tool such as PowerShell or Python it will have no problem processing all that information. You could really get a much bigger overview of all the data.

That gives you an overview of how you can access the API using PowerShell or any other scripting language. Stay tuned for more FireEye tips and insights.

Scroll to Top