So last time we learned how to upload our custom modules into Azure Automation so we can start using them in Azure Automation Runbooks.  This week we’re going to take a look at configuring a runbook to see what kind of data we can ingest from OMS Webhook data, and how we can leverage that data to pass into our functions.
Creating the Runbook Script
So first off, let’s talk about basic runbooks and running them against objects in Azure.  As previously discussed, when your automation account is created, it creates with it an AzureRunAsAccount.  This account is configured to act on behalf of the user that has access to the automation account and the runbooks in order to perform the runbook task.  In order to leverage this account, you need to invoke it in the runbook itself.  You can actually find an example of this snippet in the AzureAutomationTutorialScript runbook in your automation account.

$connectionName = "AzureRunAsConnection" try { # Get the connection "AzureRunAsConnection " $servicePrincipalConnection=Get-AutomationConnection -Name $connectionName "Logging in to Azure..." Add-AzureRmAccount -ServicePrincipal -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint } catch { if (!$servicePrincipalConnection) { $ErrorMessage = "Connection $connectionName not found." throw $ErrorMessage } else{ Write-Error -Message $_.Exception throw $_.Exception } }So now that we’ve got our opening snippet, we’ll add that into a new .ps1 script file in our preferred integrated scripting environment tool and get to work.
Now, in order to be able to ingest data from an OMS Alert, we need to be able to pass the data to our Azure Automation runbook.  In order to do so, we only need to add a $WebHookData parameter to the runbook and specify the data type as object.

Param ( [Parameters()][object]$WebHookData ) Now, we need to convert that data from a JSON object into something readable in our output.  Webhook data is presented with three primary datasets - WebhookName, RequestHeader, and RequestBody.  WebhookName, obviously is the name of the incoming webhook.  RequestHeader is a hash table containing all of the header data for the incoming requestion.  And finally, RequestBody is the body of the incoming request.  This is where the data we want to parse will reside.  Specifically, it will reside under the SearchResults property of the RequestHeader dataset.

$WebhookData.WebhookName $WebhookData.RequestHeader $WebhookData.RequestBody So let’s configure our runbook to display the incoming data to examine what we have to play with.

$SearchResults = (ConvertFrom-Json $WebhookData.RequestBody).SearchResults.value $SearchResults Publish the Runbook
Now, we’ll go ahead and save our script as a .ps1 file and upload it to our automation account with the Import-AzureRmAutomationRunbook cmdlet.

Import-AzureRmAutomationRunbook -Path 'C:\Scripts\Presentations\OMSAutomation\ExampleRunbookScript.ps1' -Name WebhookNSGRule -Type PowerShell -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName -Published And now we can see our return.

And if we check through the UI, we can see a brand-new, shiny runbook sitting in our automation account!  Now, we can configure a basic alert to monitor in OMS.
Create an Alert
For the purposes of this example, I’ve create a couple of virtual machines with network security group rules for HTTP:80 and RDP:3389 accepting connections from anywhere.  I do not recommend doing this for a production virtual machine.  /endDisclaimer
As you can well expect, these machines are throwing MaliciousIP traffic alerts in Operations Management Suite’s console:

So if we click on the MaliciousIP flag, it’ll take us to the Log Search screen.  This includes the query data that we can use for the alert.  However, you’ll want to clean up the query data a bit to generalize it.  In this example, the query is specific to the country that is displayed in the given flag.  But if we remove the country specific portion of the query, it’ll allow us to cast a wider net and get data on potentially malicious traffic from any given country.

Canned Query: MaliciousIP=* AND (RemoteIPCountry=* OR MaliciousIPCountry=*) AND (((Type=WireData AND Direction=Outbound) OR (Type=WindowsFirewall AND CommunicationDirection=SEND) OR (Type=CommonSecurityLog AND CommunicationDirection=Outbound)) OR (Type=W3CIISLog OR Type=DnsEvents OR (Type = WireData AND Direction!= Outbound) OR (Type=WindowsFirewall AND CommunicationDirection!=SEND) OR (Type = CommonSecurityLog AND CommunicationDirection!= Outbound))) (RemoteIPCountry="People's Republic of China" OR MaliciousIPCountry="People's Republic of China") Modified Query: MaliciousIP=* AND (RemoteIPCountry=* OR MaliciousIPCountry=*) AND (((Type=WireData AND Direction=Outbound) OR (Type=WindowsFirewall AND CommunicationDirection=SEND) OR (Type=CommonSecurityLog AND CommunicationDirection=Outbound)) OR (Type=W3CIISLog OR Type=DnsEvents OR (Type = WireData AND Direction!= Outbound) OR (Type=WindowsFirewall AND CommunicationDirection!=SEND) OR (Type = CommonSecurityLog AND CommunicationDirection!= Outbound)))
After testing our query to make sure it’s valid, we can now hit the alert button and configure the alert.  Here you’ll need to give it an alert name, a schedule, and number of results before it triggers the alert.  You’ll also want to select the Runbook option under actions and select the test runbook we created.  Then we hit save, and wait for our alert to trigger and the runbook to fire.

And as you can see, I didn’t have to wait long:

Validate our Data
If we click on one of the completed instances, and navigate to the output blade, we can now see the data we’re receiving from our triggered alert.  This particular data shows that inbound traffic from Colombia is attempting an RDP connection to my virtual machine.  With the inbound IP Address and target system name, we now have enough data to be able to create a full-blown auto-remediation solution.

`Logging in to Azure… Environments Context

{[AzureCloud, AzureCloud], [AzureChinaCloud, AzureChinaCloud], [AzureUSGovernment, AzureUSGovernment]} Microsoft.Azur… Computer : server1 MG : 00000000-0000-0000-0000-000000000001 ManagementGroupName : AOI-cb0eefe8-b88f-47ce-ae91-dbc46df99751 SourceSystem : OpsManager TimeGenerated : 2017-07-21T12:17:37.45Z SessionStartTime : 2017-07-21T12:16:52Z SessionEndTime : 2017-07-21T12:16:52Z LocalIP : 10.119.192.10 LocalSubnet : 10.119.192.0/21 LocalMAC : 00-0d-3a-03-ea-a6 LocalPortNumber : 3389 RemoteIP : 200.35.53.121 RemoteMAC : 12-34-56-78-9a-bc RemotePortNumber : 4935 SessionID : 10.119.192.10_3389_200.35.53.121_4935_2184_2017-07-21T12:16:52.000Z SequenceNumber : 0 SessionState : Listen SentBytes : 20 ReceivedBytes : 40 TotalBytes : 60 ProtocolName : TCP IPVersion : IPv4 SentPackets : 1 ReceivedPackets : 2 Direction : Inbound ApplicationProtocol : RDP ProcessID : 888 ProcessName : C:\Windows\System32\svchost.exe ApplicationServiceName : ms-wbt-server LatencyMilliseconds : 116 LatencySamplingTimeStamp : 2017-07-21T12:16:52Z LatencySamplingFailureRate : 0.0% MaliciousIP : 200.35.53.121 IndicatorThreatType : Botnet Confidence : 75 Severity : 2 FirstReportedDateTime : 2017-07-20T20:10:32Z LastReportedDateTime : 2017-07-21T11:25:11.0661909Z IsActive : true ReportReferenceLink : https://interflowinternal.azure-api.net/api/reports/download/generic/webbot.json RemoteIPLongitude : -75.88 RemoteIPLatitude : 8.77 RemoteIPCountry : Colombia id : 149270bc-74fc-13d0-34a9-3fd665a457b2 Type : WireData __metadata : @{Type=WireData; TimeGenerated=2017-07-21T12:17:37.45Z} `It’s a long road, and we’re almost there!  Next week, I’ll take you through my process of modifying my module to directly ingest webhook data, and how we can take our OMS queries and deploy them to other Operations Management Suite solutions using PowerShell.  See you then!
Part I - Azure Automation Account Creation and Adding Modules
Part II - Configuring Azure Automation Runbooks And Understanding Webhook Data
Part III - Utilizing Webhook Data in Functions and Validate Results - Coming Soon!