Integrating Thinkst Canary Alerts with Microsoft Sentinel

Published 6 March 2023

What is Thinkst Canary

Thinkst Canary provide cyber deception technologies and services that are used to extend traditional intrusion detection capabilities in an organisation. The main technologies they provide are Canaries and Canary Tokens. Canaries are physical or virtual intrusion detection sensors that can mimic real world systems and services such as a Windows server that exposes remote desktop protocol (RDP) or a Windows file share over the Server Message Block (SMB) protocol. You can think of them as a honeypot, example below:

Canary tokens are a file-based intrusion detection capability that can provide an alert if interacted with. These could be thought of as a Honey token, a lightweight version of a honeypot example below:

What is Cyber Deception

Deception has been used by both defenders and attackers for centuries, but we will focus on the defence for this blog. For defensive purposes deception is a way of deceiving the adversary into making a mistake, such as showing their presence on your network when performing post exploitation activities such as discovery, lateral movement etc. Cyber deception is just one layer of a well-designed defence in depth program and with good threat intelligence and business input can be an effective control against determined adversaries. It can provide a high-fidelity mechanism to detect stealthier or more advanced threats that are targeting or have infiltrated your organisation.

Purpose of the Blog

Whilst researching and developing deception capabilities I became aware of Thinkst canary and wanted to understand how it could be integrated with Microsoft Sentinel so that deception services can scale, and deployment can be automated for a modern security operations approach.

Integrating Thinkst Canary with Microsoft Sentinel

To be able to successfully integrate Thinkst Canary with Microsoft Sentinel it requires a mechanism to either push or pull the alerts from the Thinkst Canary SaaS (Software as a Service) console into the Sentinel log analytics workspace. Luckily Thinkst Canary supports the ability to send alerts to a webhook as seen below:

Next, we need a method to receive the alerts in Azure. To do this Azure Logic Apps can be leveraged using the capability to handle incoming HTTP (Hypertext Transfer Protocol) requests through the “When a HTTP request is received” request trigger in Azure Logic Apps. This blog post on Microsoft Learn covers this capability in greater detail: Handle inbound or incoming HTTPS calls - Azure Logic Apps | Microsoft Learn. Once added to our workflow we can copy the HTTP POST URL and add it to the configuration in the Thinkst Canary cloud console.

Now that we have a mechanism to receive the HTTP data from Thinkst In the next step of our logic app workflow, we are going to use the Azure Log Analytics Data Collector action to send the data to the log analytics workspace associated with our Microsoft Sentinel. Again, you can get more detail on this capability on Microsoft Learn: Azure Log Analytics Data Collector - Connectors | Microsoft Learn.

You can also define the schema here if you desire using the below example payloads.

Canary Alert

Canarytoken

Once the Send Data action is added it needs to authenticate to your log analytics workspace using the workspace ID and key.

These details can be found in the settings section of Microsoft Sentinel as illustrated in the images below.

Then navigating to the agent’s blade where you can view the workspace ID and Key.

After configuring the connector to authenticate with the Microsoft Sentinel log analytics workspace the action must be configured to use the body of the HTTP request from the previous workflow step and will also require you to provide a name for the custom log table that will be created to store the Thinkst Canary events.

That concludes the logic app element of this integration next, we will look at what we have received in Microsoft Sentinel and identify how we can produce analytics for alerts received into the custom log analytics table. For now, we should have implemented a mechanism which looks something like the below image:

in the below diagram you can see how this mechanism can work to integrate alerts with Microsoft Sentinel via a Logic App.

Microsoft Sentinel Detection Analytics

In Microsoft Sentinel we will want to start producing alerts from the events received by Thinkst Canary sensors or tokens. Microsoft Sentinel provides several different mechanisms for alerting but as these events are in a single table and are high fidelity / severity we want to create an analytic that can provide near real time (NRT) alerting and incident creation. With that in mind we can use Microsoft Sentinel NRT analytics rules to get the job done. More on NRT rules here: Work with near-real-time (NRT) detection analytics rules in Microsoft Sentinel | Microsoft Learn

Evaluate the logs

Before creating the analytics rule, we want to view the types of logs being received to do this navigate to the logs blade in Microsoft Sentinel and confirm my custom table is present.

Next, check if any Thinkst Canary event data has been received from the logic app. The image below confirms data is being received from the Thinkst Canary cloud console. There are two types of alerts CanaryIncident and CanaryTokenIncident and each have a different alert schema. There are many different alert types and with this in mind we may need to be creative to automate alert generation that is security analyst friendly and can still provide the metrics we need in the SOC (Security Operations Center).

Develop the Analytic

Firstly, when creating the analytics rule, we want to ensure it has appropriate metadata. The image below shows how this alert has been configured ensuring MITRE ATT&CK mappings have been completed and an appropriate severity assigned. This alert is going to be for the Thinks Canary which is an IDS (Intrusion Detection Systems) sensor.

Next, we want to set the rule logic, as these are already alerts there is no detection as such but we do want to promote the alert to an incident, make sure we do not include Canary Token alerts in this analytic and I also wanted to create a custom field to our Thinkst Canary cloud console just encase the analyst needs to dig deeper into the alert or grab additional metadata that can only be found in the console.

Once the alert logic is in place, relevant entities need to be mapped so the alerts can be enriched with key metadata and context when they are surfaced in Microsoft Sentinel. More information on entity mapping here on learn: Map data fields to Microsoft Sentinel entities | Microsoft Learn

Finally, to overcome the challenge of having multiple Canary alert names being created by a single analytic it is possible to utilise the alert details capability to generate dynamic data using unique event fields found in the log analytics table, more info here on this capability: Surface custom details in Microsoft Sentinel alerts | Microsoft Learn. The fields used in this analytic are listed below:

Description_s
Intro_s
CanaryLocation_s
AlertUrl
AlertType_s
We also want to setup event grouping to create a unique alert for each event.
Once the alert settings are configured appropriately, we need to configure the incident settings to ensure that incidents are created and grouped according to our requirements.
First, we will enable incidents to be created by the analytics rule.
Next, we will enable grouping of alerts into a single incident where the alert details Name field and the alert entities, IP address, and Host fields are the same. This is used to reduce alert fatigue and ensure alerts correspond to the same alert type so an analyst can follow the appropriate alert response guide in an efficient manner. It also opens the door up to utilising further automation and playbooks to enrich or respond to an alert based on the specific alert name and type.
For now, there is no requirement to add any automation to this analytics rule, and the rule can be saved.

For the Thinkst Canary Token Alert I have followed the same process but mapped one or two fields differently as the schema contains slightly different fields. The fields that need to be mapped to generate dynamic alert metadata can be seen below:
Description_s
Intro_s
Reminder_s
AlertUrl
AlertType_s

Alert Validation

It is important to validate the analytics rules work as expected. To confirm the analytics rule is working we can trigger some alerts on our Thinkst Canary sensors and tokens to see if they show up in Microsoft Sentinel as incidents.

As you can see, we have some Canary Token alerts in the queue.

The dynamic content generation has worked by creating dynamic alert names and description content as seen below.

In this analytic custom enrichment has been added using custom field mappings to provide greater detail and context in the comments section of the alert:

Wrap-Up

So hopefully that has been useful and provides the building blocks for the integration of Thinkst Canary deception technology with Microsoft Sentinel. The content has been shared with Microsoft Sentinel community and should hopefully be available shortly via the official GitHub.

Thanks for reading, if you ever need any support or help with Microsoft Sentinel, please feel free to reach out to the team at Bridewell who have extensive experience across the Microsoft 365 and Azure Cloud Security stacks.