Overview⌗

Adversary-in-the-Middle (AitM) proxy based phishing has historically been an effective method of bypassing basic authentication controls like SMS and TOTP MFA. Unlike credential phishing through a cloned login portal, an AitM attack proxies the legitimate authentication flow in real time and captures user session details, which an attacker can reuse without further user interaction.

The strongest preventative control is phishing-resistant multifactor authentication, like FIDO2 or passkey solutions. These are designed to prevent authentication from a different domain than the legitimate domain with which the hardware token or passkey was registered.

T = r = a = d = i = A t = d i = v o = e n = r a = s l = a = r P = y h = i = s = h = i = 5 n = . g = = s l a C c w w = 1 2 i 3 i 4 n a r 6 i i = . . t . n . d p e . t t = e k t d h h = C S D U i u e A = o e w e t s n r n t s C = p r / l o e p e t t t l = y v i r u i e o o = e s v u t v a m l n = H a e s v s a l p e e = T p m r e i l s t n d = M h e r s c i = L i p i r d l c L = + s s h t e o r o = C h t i s d g e g = S i y s e i d i = S n l h l n n s n = g i i i t = n n n i P = g g k a o = l r = s C t = l a = o l = n B = L C e L l e l U d e o g o s g M c i n e L i F k t e r o t A e i d g i d m i m ! a L n a t o / t e g S e i S L n O L o / o g S g i S i n O n / / S S S S O O

 

A = d = v = a = n = c = e = d = = P = h = i = s = h = i = n = g = 1 C 2 C 4 o t = . r . r . f o w = e e k i = E d F d S s e t = n s o s e e n h = t r n s / = e + w + d s c P = r a s i o r = s M r M o o o = F d F c n k x = A A s A L S o i y = t * e S p e = t g O y s A A / = a ( i d p = c A t P v p A = k i i o e l d = e t m r r i v = U r M a t s c e = s ) t a a 5 a r = e P e l r . t s = r r y i a = o L U w o r = x o n i n y = 4 y 3 g a t = . . i u h i = n t n = S t S t / h S = e o e o o e t = n k n k r s h = d e d e i s e = w s n s n z i = i / / e o M = t s c s c d n i = 5 h e o e o d = . s o s o A T d = S s k s k c o l = A e i i i i c k e = u s o e o e e e = t s n s n s s n ( = h i s / A = o o C i = r n o t = i o M = z T k ) = e o i = d k e = e s A n c / c C e o s o s k i e s A p p l i c a t i o n

* Phishing-resistant multifactor authentication methods like FIDO2 security keys or passkeys mitigate this step (#2), unlike number-matching or TOTP methods that are not explicitly tied to the domain of the legitimate service.

For organizations that want additional defense-in-depth, deception technologies can provide a complementary layer by detecting proxied login portals and phishing infrastructure prior to credential compromise. Deception helps address the challenge presented by the fact that attacker infrastructure is not something that can be logged in a SIEM for alerting. Stolen session tokens can remain undetected until they are used against production systems; by then, detection depends on last-resort signals such as impossible travel or anomalous sign-in activity. Alerting on unexpected domains that use the same branding as a known login portal for your organization via deception technology gives advanced notice that allows for proactive network blocks and hunting for both traffic to and emails linking to a potential up-and-coming credential theft portal.

Canary Tokens⌗

Canary tokens are a form of deception technology that act as tripwires. Once they are accessed, they trigger a callback to a listening service, similar to a web beacon or email tracking pixel. Note that “canary token” is also the name of a canary token service operated by Thinkst Canary.

Thinkst Canary researchers developed a mechanism for detecting AitM phishing by using discrepancies in the referrer header of page loads between legitimate login portals and proxied login portals by using their canary token service. By loading a canary token via CSS, the canary listener can trigger an alert when the token is loaded with a referrer other than the legitimate portal.

Example HTTP request to a page containing a canary token, when the domain is the expected domain name:

HTTP request flow loading a page with a canary token where the referrer domain matches the actual domain.

When the the request is performed through a proxied portal, HTTP Referrer header mismatches (step #6):

HTTP request flow loading a page with a canary token where the referrer domain does not matche the actual domain.

Ingesting Canary Triggers into Sentinel with Azure Logic Apps⌗

While Thinkst Canary provides a notification mechanism to receive emails on cloned site visits, email isn’t conducive to proper case/incident management or alert tuning. Security teams can ingest these events into a SIEM where analytic rules can be tuned and incidents can be generated for assignment and remediation tracking.

Azure Logic Apps are a low-code/no-code, event-driven automation platform within Microsoft Azure. Logic Apps are an ideal candidate for this use case because Thinkst Canary tokens can be configured to send a webhook to any arbitrary URL, and Logic App workflows configured to receive an HTTP payload as a trigger can filter and transform the payload, then forward the resulting data to a Log Analytics workspace connected to Microsoft Sentinel.

Request flow with detection logic added

A deployment template containing all necessary Azure resources is available here.

Deployment Instructions⌗

Azure⌗

Azure Portal:

Click the “Deploy to Azure” button, or download the ARM template from GitHub and navigate to the custom deployment service in the Azure Portal. Select “Build your own template in the editor” and upload the ARM template file.

Deploy To Azure

Enter the name of your Microsoft Sentinel workspace in the “Workspace Name” field. Optionally, customize the names of the Data Collection Endpoint, Data Collection Rule, and Table Name for canary token events.

ARM template project details including the subscription and resource group in which deployment will occur; includes instance details like region, workspace name, data collection endpoint + rule names, and table name.

Click “Review + create” to validate, then “Create” to provision.

Summary view showing what parameters were set to create 7 Azure resources.

Upon successful deployment, the following resources are created:

  • Canary-Token-Webhook-Endpoint: The Logic App workflow with an HTTP Request trigger that receives canary token payloads.
  • CanaryTokenDCE: The data collection endpoint
  • CanaryTokenDCR: The data collection rule
  • CanaryTokenEvents_CL: The Sentinel table where canary trigger events are logged.
  • ASimAlertEventThinkstCanary and vimAlertEventThinkstCanary: The Sentinel Workspace Functions that normalize CanaryTokenEvents_CL events to the ASIM Alert schema. ASimAlertEventThinkstCanary acts as the base parser; vimAlertEventThinkstCanary provides additional parameters for improved filtering performance.
  • workspace-name/Microsoft.SecurityInsights/generated-rule-guid: The Sentinel analytic rule titled “Canary Token Interaction” that generates alerts and Sentinel incidents when new canary trigger events occur.
Overview screen showing the resources created by the ARM deployment.

AZ CLI:

az deployment group create \
    --resource-group Your-Resource-Group-Name-Here \
    --template-file azuredeploy.json \
    --parameters workspaceName=Your-Sentinel-Workspace-Name-Here

Granting the Logic App Access to Your Sentinel Workspace⌗

To allow the Logic App to write canary trigger events to the Sentinel workspace via the deployed Data Collection Endpoint (DCE)/Data Collection Rule (DCR), its system-assigned managed identity must be granted the “Monitoring Metrics Publisher” Azure role with a scope that includes the DCR.

Shows the start of the role assignment process on the DCR; navigating to the DCR, selecting Access control (IAM), clicking Add, and clicking Add role assignment. Shows the role Monitoring Metrics Publisher selected before clicking Next to proceed. Shows the Assign access to value set to Managed identity, and the dialog for selecting the Logic App system assigned managed identity; the Canary-Token-Webhook-Endpoint Logic App is selected. The role member selection page after the Logic App has been selected, with the Review + assign button highlighted. The Add role assignment Review + assign page showing the assignment to be created, with the final confirmation button highlighted.

Configuring a Canary Token⌗

Step 1: Retrieve the Logic App Webhook URL

Open the “Canary-Token-Webhook-Endpoint” Logic App in the Logic App Designer. Click the “Canary” trigger and note the value in the “HTTP URL” field. HTTP POST requests sent to this URL will be processed by the workflow and written to the Sentinel table via the DCR.

The Logic App designer view highlighting the location of the webhook URL to use in the next step. It is located in the trigger, labeled Canary, and is in the field HTTP URL.

Step 2: Create and Configure the Token

Visit https://canarytokens.org/nest/ and select the desired token type - for example, “Azure Entra ID login” for cloned Entra ID portals, or “CSS cloned website” for other identity providers such as Okta that support custom branding.

The Canary Tokens creation form. The domain of protected website is set to the FQDN of the login/SSO portal. The Mail me here when the alert fires field is set to an example email address. The Remind me of this when the alert fires is set to 'Orgname Login Portal (production)'. The Notify me here when the alert fires webhook notification field is set to the Logic App webhook URL retrieved in Step 1.

A. Enter the FQDN of the web resource to which the canary token will be added (e.g., login[.]your-organization[.]org). If multiple FQDNs require coverage, create a unique token per domain - reusing a token across domains will cause it to trigger on every visit to the second domain.

B. Enter an email address to receive alerts and manage the token.

C. Provide a descriptive label for the token to differentiate it in logs and alerts.

D. Paste the Logic App trigger URL. When the referrer domain does not match the expected domain from step A, a payload containing request details is sent to the webhook.

After completing the form, click “Create Canarytoken.” You will receive a CSS snippet to paste into the HTML or branding configuration of your web page or login portal. When this image is loaded from a non-matching referrer domain, the canary token webhook triggers and the event is logged in Sentinel.

Confirmation page reading 'Your CSS cloned website Canarytoken is active!'. It shows a CSS snippet setting the body background to an image on AWS CloudFront and includes links for additional documentation.

Optionally, email notifications for canary token triggers can be disabled if relying solely on Sentinel alerts via webhook ingestion.

The dialog to manage tokens within the Canary Tokens portal highlighting the 'Email alerts' setting, which is toggled to 'off'

Detection⌗

Once deployed, Canary Token triggers will send a payload via webhook to the Logic App, logging the payload in the Sentinel Log Analytics Workspace. The analytic rule will create an incident in Sentinel.

Logic App Workflow Run⌗

A screenshot of the Logic App run history 'Compose Log Payload' step, which shows that the Canary Token payload details like Channel, Token Type, Source IP address, token ID, memo, and additional IP information are present.

Sentinel Log (ASIM normalized)⌗

A screenshot of Microsoft Sentinel's log view, showing a parsed Canary Token log with normalized field names.

Sentinel Alert/Incident⌗

A sample Microsoft Sentinel alert for Canary Token Interaction. It includes entities for the domain and URL associated with the potential adversary infrastructure and (redacted) source IP address. A close-up screenshot of the description and entity information of the incident shown in the previous screenshot.

While phishing-resistant MFA remains the strongest defense against AitM attacks, deception can add valuable detection coverage when broader protections are still being rolled out. Integrating canary token hits into Microsoft Sentinel via Azure Logic Apps helps security teams strengthen defense-in-depth with earlier visibility and actionable alerts.