Use powershell to add a tag to a MS Defender device

Iron Contributor

Hi,

 

I'm automating some security tasks with the help of powershell. One of the things I'm trying to automate now is the creation of a tag on a Defender device, but didn't found much info about it.

Anyone sucessfully added tags to Defender devices using powershell?

 

Thanks

 
 
11 Replies

yes, the API for this is straightforward enough, it allows add or remove a tag via POST request

 

$API = "machines/" + $DeviceId + "/tags"

$Body = @{"Value"=$Tag;"Action"="$Action"}
$Body = $Body | ConvertTo-Json

,  

@jbmartin6 

Thanks for the tip. I was already able to do a part of the job, which is extracting the "machineid" from Defender, with this code:

$apiUrl = "https://api-eu.securitycenter.microsoft.com/api/machines?`$filter=computerDnsName eq '$hostname'"
$response = Invoke-RestMethod -Method Get -Uri $apiUrl -Headers $headers
$machineId = $response.value[0].id

And it's fine as I got the "machineid". But then I'm using this code for the addition of the tag.

$Tag = "tag-test"
$apiUrl = "https://api-eu.securitycenter.microsoft.com/api/machines/$machineId/tags"
$Body = @{"Value"=$Tag;"Action"="Add"}
$Body = $Body | ConvertTo-Json
$response = Invoke-RestMethod -Method Post -Headers $headers -Body $body -Uri $apiUrl

And I've got the error:

"code": "Unauthorized",
"message": "Invalid Authorization payload."

But on the api permissions I've added the permissions which are written on the documentation, which are "Machine.ReadWriteAll" and "Machine.ReadWrite".

Is there any way I can try to debug why doesn't this session has the permission to write the tag?

 

Thanks

 

 

That error suggests the problem is in the headers, but if you were able to use the headers successfully to get the machine ID.. Maybe the scope you are using when you request the authorization token?
You could double check using the MDE API explorer, but that won't help if the issue really is in the authorization header or token.

@jbmartin6 

I did that and don't know how but the token issue seems that is solved. Now I've got the same piece of code but with another error, which is:
Invoke-RestMethod:
{
"error": {
"code": "InvalidRequestBody",
"message": "Request body is incorrect",
"target": "|5ca2fd80-4d6cdfba5c72ce16."
}
}

 

But the code is just the same. The $body variable has this content:

{
"Value": "Vulnerability-Update",
"Action": "Add"
}

Which is aligned with the body which is used on the API Explorer in MDE portal.

Any way to debug this?

 

Thanks

That's a puzzle. It should work as you describe, and that's how my code works as well. I would work through your code line by line, and replace your variables with static strings until you determine if something is altering the data in a way MDE API doesn't like.
But to answer your question, I don't know of a log or tool on the MDE side for debugging APi requests our code generates. You could use Fiddler or a similar local proxy tool (Postman maybe?) to look at exactly what your code is sending and examine the full response.

@jbmartin6 Thanks for the tips.

Finally it's working. First, instead of using a variable on the creation of the body, like this:

$Body = @{"Value"=$Tag;"Action"="Add"}

I removed the variable and added a value and it worked. Then I start messing with the variable values and then, the same variable value I had before worked, without really understanding why, but now it's working fine.

 

Great that it is working! I had a similar experience trying to run hunting queries using the API, there were some character escapes needed but then sometimes it still failed. I'm sure there is some technical wrinkle of strings or powershell that we are missing.

@jbmartin6 

Well, this is really odd. I had it working, but of course it was in an area of the script for testing. Then moved the code to the correct area of the script and today went to test the full script and it's not working again, prompting the same error of the "InvalidRequestBody".

So now I'm not really sure what is the problem, but it's not working anymore and don't have a clue why.