Dan Kiraly: Hi, and thanks for tuning in I'm Dan Kiraly and I work as a researcher in Optiv’s research and development group. This is the first video of a technical video series demonstrating some of the challenges that we had to overcome in developing a way to perform efficacy testing against several vendors with no human interaction. It all started in 2019, when we were wrapping up our endpoint testing, we used a solution called Verodin, which is now been purchased by Mandiant and it's called Mandiant Security Validation. We use this solution to test the efficacy of nine different endpoint vendors, and anyone who has performed this type of testing or any competitive endpoint testing, Bake-Off, knows that it's a lengthy process to create an environment, to install all of the necessary software, the vendor sensors, to perform that testing, to validate the results and, you know, to provide some type of output that shows scoring between different solutions.

And now we were able to automate that entire process, start to finish. In past zero trust posts, I covered how Microsoft automation can be used for a number of things how it can be used for patching software testing. And as a part of that series, I even covered how an environment can be spun up. This environment than I used was for robotic process automation testing. And I, I wanted to take some of the concepts found in these posts, even some of the scripts in this one and apply them to a new idea. I wanted to see if I could, you know, use some of these scripts, some of these foundational ideas and introduce some new technology and achieve fully automated end point evaluations.

One of the first hurdles I needed to overcome, and I've done this in the past, but I just wanted to revisit the idea in case some of you don't know, is how can the power platform talk to something that's on-prem. So here on the right hand side in Optiv C lab in our virtual environment, we're running Mandiant Security Validation. This is the tool or solution I want to use to perform efficacy testing against our end points. So how can we allow power automate to talk to Mandiant Security Validation? How can we get it to access the APIs? So Microsoft has this idea of an on-premise data gateway. Microsoft has good documentation on what the on premise data gateway is, how to install it and how it works.

The on premise data gateway acts as a bridge, almost like a proxy between cloud resources, whether that's Azure resources or anything the power platform, and those on-prem resources that you're looking to get access to. So it extends that Azure functionality that power automate functionality to on-prem hosts or applications. Another benefit to the on-premises data gateway is the ability to force the data bus, the communication to use HTTPS as the protocol for communication. And that way, as long as you have 4, 4, 3 open outbound to certain Microsoft sites, you have the ability to communicate without having to poke a hole inbound in your firewall. You can see the addition of the windows VM that has the on-premise data gateway. It's an update to our architecture slide that was shown before. So now we have a path to talk to Mandiant Security Validation, but the power platform doesn't know how to actually talk to it because there's no connector made for it.

And just to prove this, we'll do a quick search. We're in power automate, and we're looking for the current connectors. So I'll type in Mandiant and there's none. The product also used to be known as Verodin before it was acquired. And we can see that it's listed there there's none listed as well. So we have to create a custom connector. And if anybody's wondering why I'm working in power automate instead of logic apps, I do a lot of work with desktop flows or robotic process automation that's offered by Microsoft. So I have a lot of connectors already established, and I didn't want to go ahead and recreate that work. As far as custom connectors go, you can see that I don't have any listed. And that's the purposes of this demonstration is to show how we can create a custom connector to Mandiant Security Validation. For those of you who are unfamiliar with Mandiant Security Validation, it's a breach attack simulation tool. You use it to test the efficacy of certain security controls, whether that's at the endpoint or network. And what we have here is a basic topology. This is a lab environment with just four hosts in it, and we want to execute actions or simulations against these hosts. What I'm going to do is look for a very particular action that will serve as the example used in the creation of our custom connector.

So I'm going to look for one that I've created. We'll use a defensive API that leverages Ms. Build. This is the action right here. If we were to continue on executing this action through the UI, we would have to select an endpoint. Once an endpoint is selected, then we can click the run now button and execute that action against that host. But what we want to do is perform that through the API, so we can create the connector in Microsoft to do the same action for us or that same task. Mandiant has decent documentation within the UI for the API, with some examples, and I'm not going to go through them all. What we're really concerned about for this connector is listing out the actions we're going to look or find a particular action. We're also going to need to know which end point or which node that we want to execute against.

So we're going to have to look in our actors, or actually it's a typology under nodes. So let me scroll down to typology. And this will give us an active understanding of the nodes that are pending and then the ones that are active. And then once we have that information, we want to execute an action. So with knowing what action ID, as well as what node ID, then we can run an action. Again, that action is just one attack technique that's going to be executed against the endpoint. What I'm going to do is move over to post man. This is where I'm going to try these requests out. These gets to these posts and make sure everything is executing properly. Then I can export it and import it into power automate as a custom connector. The base URL is just the server name. Then we follow it by typology nodes. And we're going to get that back in JSON form.

And that's exactly what the API documentation instructs us to do. It's a simple get request. Basic authentication is needed to make this request. So you can see, I have a username which is API user, as well as a demo password for this video. Now, when I hit send, I'm going to get back all of the pending, not yet registered hosts, and forgive me for not explaining this earlier. Every host that we're looking to test against has to have the Mandiant Security Validation agent installed on it. And during that process, there is a token that's needed. So that sensor, that endpoint, can register with the Mandiant and director, this returns all nodes that are looking to register with the director, as well as those that are registered. And then I have all of the information I need about those individual nodes, those hosts. So now I know which one I want, or I can choose one that I want to execute against. The next thing I need to do is list the actions and seek out an action ID for the specific action we want to test against.

It can be done through a search query, but I'm just using the simple list and then a control F to find the PRS defensive evasion execution, Ms. Build action. So I'm just going to copy this information. I'm going to paste it in here. There is the action that I'm looking for and right up top is that action ID. So 53 is the action ID for this particular simulation. Now, when I put that 53 in the value, that's only half of the information I need to actually execute the simulation. What I need now is a host to execute it against. And I'm choosing a host that is registered. That's a windows 10 hosts because the action or the simulation is designed to execute against windows. It's number 44. I've put those in already. When I hit, send, what's going to happen is that action is going to kick off and instruction is going to be sent down to that end point. So we can see that it's, the request has been made that post they action is in a waiting state. And if I go to the, UI put in the job number that was returned to me, so I go to jobs and in 343, we're going to get the state of that action here. We can see, I see that it's preparing, it's the correct host as well as the correct action or simulation that we want to execute.

Now that I verified that my API requests work, I'm going to export them in a version one collection, which is deprecated, but that's the version that Microsoft uses. So, I'm going to export those four requests. Only three. I showed one we're going to use later on. I've successfully exported them. It's just a JSON file. And now when I go back over to my custom connectors, I'm going to choose the option to create a new custom connector. And it gives us a few options of how we want to create that connector. Again, we're going to use postman. We're going to import a V1 collection. We have to name that collection and let's name it, Mandiant Security Validation. Just put that in here. And then we have pointed at the file that we export it from postman, which is in our automation folder. And then there's our Mandiant Security Validation post JSON, file.

I can take a little bit of time to process depending on how much information you're bringing in, but now you can see, we have our description for this custom connector. We know that it's an on-premise. So we're going to use, we're going to connect through a pre-existing on-premise data gateway that I already installed. We have our base URL already there, we're going to need to identify what type of authentication we're going to use and what labels we're going to use for those. I am actually going to type in user name here and as well as password for the parameter labels, we'll move forward to definition. And what we're going to see is we already have on the left-hand side under actions, there are four. Three I've showed you when we're going to use a little bit later and that's that list evaluation ID. But if we go over to run action, you can see that we have a summary. We have the URL information list Actions, has the same thing, same with lists nodes.

So everything we need is already there. We could use their swagger editor editor if we wanted to customize it or tweak it or change at all. But now I want to test it. And before I test it, I actually have to create the connector and creating the connector involves adding the username password, as well as the gateway we want to execute through. This is where we put in the username, that API user, as well as the password, the gateway, these are the gateways that I have registered with various automate or Azure services. I have one called the endpoint evals. That is the one that I'm going to use to talk to managed security evaluation. I'm going to put in that API user name as well as the password for the basic authentication. And once I do that, we have the ability to then create the connection. And it's going to make sure that that connection can execute through that gateway.

Now can hit create connection, with that connection made, now we have the ability to test our API calls. Now power automate knows to execute those calls and use the on-premise data gateway as that route for communication, we have chosen the connector and then we're going to list the actions. We test that operation and hopefully in a few seconds, perfect. We get the information back just like we saw in postman. So now we have power automate communicating through our on premises data gateway to Mandiant Security Validation. And we know now that list actions and list nodes both work. I'm not going to use the run action now, or list evaluation ID. We're just going to close this out and power automate under custom connectors. Now I have Mandiant Security Validation listed. Next let's create a very basic flow. Probably one of the most simple that we can create an instant cloud flow with a manual trigger, where we're going to use that custom connector to return some information.

We have to give it a name. So I'll just write MSB testing or, or connector test. it's manually triggered, so we're going to create it. Now we have to add a step, that next step we're going to go under operation. We're going to go to excuse me, custom. And under custom. Now we have Mandiant Security Validation. And if I click on that, we have the four different actions that we created from postman here. I'm just going to list the nodes out. There's no additional steps necessary, can save it. And then I can run a test against it.

Once this cloud flow, this instant flow saves, which it has. I can make sure I have a proper connection and I can hit test. Test is also going to validate that the connection exists going to be a manual test. Perfect. Again, the connection was validated. Now I can execute or run that flow. And that flow is just to list the nodes through Mandiant and using our on premises data gateway. Perfect. Our flow run has tested correctly, there were no errors. We could see that it only took two seconds. When I go to check the output, I can see the JSON body. I could see that power automate has successfully talked to Mandiant Security Validation, requesting the nodes through our on-premise data gateway. And that will conclude the first part of this series. We are going to continue to build on this lab architecture diagram. Next, we need to figure out how we're going to create our test environment. We know that we want to do it in Azure with Azure VMs, but how is that going to be possible through power automate? I appreciate everybody taking the time to listen, and I hope you continue to follow the videos in this series. Thank you