Malicious Clicks allowed (click-through)

Hunt Hypothesis

Users may be bypassing Safe Links security controls by clicking on malicious URLs, indicating potential social engineering or phishing attempts. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate user interactions with malicious content before significant damage occurs.

KQL Query

let TimeStart = startofday(ago(30d));
let TimeEnd = startofday(now());
UrlClickEvents
| where Timestamp >= TimeStart
| where IsClickedThrough == 1
| where isnotempty(ThreatTypes)
| make-series Count = count() default = 0 on Timestamp from TimeStart to TimeEnd step 1d
| render timechart

Analytic Rule Definition

id: ba4f7e56-a2f8-4a30-b848-200fdc7fc3a2
name: Malicious Clicks allowed (click-through)
description: |
  Visualises malicious URL clicks that were allowed through Safe Links over time, helping analysts identify when users bypass security controls and click on malicious content.
  Based on Defender for Office 365 workbook: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/part-2-build-custom-email-security-reports-and-dashboards-with-workbooks-in-micr/4411303
requiredDataConnectors:
  - connectorId: MicrosoftThreatProtection
    dataTypes:
      - UrlClickEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  let TimeStart = startofday(ago(30d));
  let TimeEnd = startofday(now());
  UrlClickEvents
  | where Timestamp >= TimeStart
  | where IsClickedThrough == 1
  | where isnotempty(ThreatTypes)
  | make-series Count = count() default = 0 on Timestamp from TimeStart to TimeEnd step 1d
  | render timechart
version: 1.0.0

Required Data Sources

MITRE ATT&CK Context

• Tactic: InitialAccess
• Technique: T1566 — T1566

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Email and Collaboration Queries/URL/Malicious Clicks allowed (click-through).yaml)

False Positive Guidance

• Scenario: User clicks on a legitimate link in an email from a trusted vendor
  Description: A user receives an email from a known business partner containing a link to a legitimate document or resource. The user clicks the link, which is flagged by Safe Links as a potential threat, but the click is allowed.
  Filter/Exclusion: Exclude links from known trusted domains (e.g., @example.com, @trustedvendor.com) using Safe Links’ domain reputation settings or by adding these domains to the Safe Links allowlist.

• Scenario: Scheduled job or automation script accesses a public API endpoint
  Description: A system administrator runs a scheduled job that connects to a public API (e.g., GitHub, Azure DevOps, or a third-party service) to fetch data. The API endpoint is mistakenly flagged as malicious by Safe Links.
  Filter/Exclusion: Whitelist the specific API endpoints (e.g., https://api.github.com, https://dev.azure.com) in Safe Links or use a custom rule to exclude traffic from known automation tools like PowerShell, Python, or curl.

• Scenario: User clicks on a phishing link in a test environment
  Description: A security team member clicks on a test phishing link hosted in a sandbox or a controlled environment to simulate a phishing attack. The link is flagged by Safe Links as malicious.
  Filter/Exclusion: Create a Safe Links policy that excludes traffic to internal test domains (e.g., testphishing.example.com) or use a custom rule to exclude traffic from specific user groups (e.g., SecurityTeam).

• Scenario: User clicks on a link to a legitimate cloud storage file (e.g., OneDrive, SharePoint)
  Description: A user clicks on a link to a file stored in OneDrive or SharePoint that is shared internally. The link is flagged as suspicious by