Making Airlock Easier

 We recently switched from using Microsoft's built-in application AllowListing technology Applocker to a 3rd party product named Airlock. The reason for switching was due to a change Microsoft made in Intune that limited the amount of XML which could be posted for the policy config. We couldn't get around it and didn't want to switch back to using Group Policy to manage Applocker so we made the switch.

We've been very pleased with the switch for several reasons which include ease of management and speed of applying policy changes. We didn't like having to monitor the GUI for blocked executables and wanted to be able to quickly allow a blocked executable from our phones without having to log into the Airlock console. We ended up creating a nice solution using a combination of the following:

  • Airlock Restful API
  • Syslog Collector
  • Azure Sentinel SIEM
  • Azure Sentinel Syslog Connector
  • Azure Sentinel Playbook/Logic App

  1. Airlock Server is configured to export Syslog events to a Linux VM configured as both a Syslog Collector and an Azure Sentinel Syslog Connector
  2. Syslog events are sent to the Azure Sentinel SIEM
  3. For each blocked application an Azure Sentinel Analytics Rule is tripped which runs an Azure Sentinel Playbook (Logic App).
  4. The Logic App performs a POST to the Airlock API to query whether the blocked executable's hash already exists as an allowed application in the Airlock database
  5. If the hash does not exist in the Airlock database as an allowed application then an approval email is sent to an administrator containing the details of the blocked application
  6. The administrator can click either Approve or Reject on the email
  7. If the administrator approves the application the logic app moves on to perform a POST against the Airlock API to allow the blocked executable's hash
Setup:

In Azure Sentinel, configure the Syslog connector as follows to be sure you get the correct logs containing blocks from Airlock:


Create an Analytics Rule in Azure Sentinel so that we can run a Playboook/Logic App when the Analytics Rule is tripped:


Within the Analytics Rule you will set the Automated Response to run your Playbook (Logic App) which we have not created yet:


Now let's go over the Azure Sentinel Playbook (Logic App) in the Logic App Designer within Azure Sentinel. The first step is just telling the Playbook to run when the Analytics Rule is tripped. The second step simply gets the entities from the Syslog message that tripped the alert. 

Initialize Variables is just something we need to do so that we can use these variables later on.


Next, we initialize one more variable and then apply a Parse JSON action to the FileHashes entity which is an output from the Get FileHashes step above.


NOTE: The Schema in the Parse JSON step above should be set as follows:

{
    "items": {
        "properties": {
            "$id": {
                "type": "string"
            },
            "Algorithm": {
                "type": "string"
            },
            "Type": {
                "type": "string"
            },
            "Value": {
                "type": "string"
            }
        },
        "required": [
            "$id",
            "Algorithm",
            "Value",
            "Type"
        ],
        "type": "object"
    },
    "type": "array"
}

Below is an overall view of the next steps which we will expand on later. Basically, we are applying a For each to to the JSON  Body from above which have been mapped to useable entities due to parsing the JSON of the Analytics Rule (which contains the Syslog message from the Airlock Block).

We'll need to do some string manipulation to the output to parse out what we need and I chose to use JavaScript to do this.


Expanding on the steps above, we first pull the contents of the blocked executable syslog message from the parsed JSON of the Analytics Rule. An example of what that looks like is as follows:

FileActivityMessage|19/11/2020 10:21:31 AM|p-vm-rsappproxy|SYSTEM|C:\Packages\Plugins\Microsoft.Powershell.DSC\2.80.2.0\bin\|update.cmd|4560e58381e1a18d8ea04217ede26b13abd24ee039d2fd2440c00a465a669f2c|5ec3d336ecb353a51dc9aec54b0727f0|90d4b39de01db8bc638b28485f9b8c1fb538c67a|Not Signed|Servers|Server Enforcement|Blocked Execution|cmd.exe|

Our goal is to get the SHA256 hash of the blocked file so this is where the string parsing using JavaScript comes into play:



Set Variable 2 is where we assign the hash value we just obtained to the variable named filehash:


Next we need to pull out the computername and filepath of the blocked executable from the output of the Analytics Rule (Syslog message). Again I chose to use JavaScript to do this:


Now we are going to POST to the Airlock API to determine if the hash value of the blocked executable exists in our Airlock database already as an allowed application:


Next we will parse the body of the result from the POST to the Airlock API:


The Schema was generated from a sample of the POST request. It's too large to paste here but just click the "Use sample payload to generate schema" link and paste in the results of a POST request response.

Next we need to get the application ID assigned to the blocked executable. If there is any application ID assigned to the blocked file then we know that it already exists in our Airlock database as an allowed application:


The best way I found to determine if the blocked executable already exists as an application in our Airlock database is to look for the presence of the string "[{" in the response from the POST.



If the presence of the string "[{" does not exist before the application ID included in the response from the POST to the Airlock API then we know the blocked executable does NOT exist in the database yet as being part of an allowed application so we will send an approval email (shown below):

If Approve is selected on the email then the Logic App will continue on and perform the following POST to the Airlock API. The POST does NOT yet add the hash as an allowed application. It just adds the hash to the Airlock database with the path to the filename. The path here really doesn't matter, it just needs a path.




Now that we've added the hash of the blocked executable to our Airlock database we can link it with an application using an application ID we've created beforehand to be a catch-all for these automated approvals. The API call to do this is below:


The final step is to send an email to all of us indicating one of us approved the executable to run on all computers that the catch-all application is assigned to.





Comments

Popular posts from this blog

Auto-installing extensions on Firefox using Intune

Disable DNS over HTTPS in Firefox using Intune

Moving Applocker control from Group Policy to Intune