Ingest IOC from Google Threat Intelligence into Sentinel
Hi all, I'm string to ingest IOCs from Google Threat Intelligence into Sentinel. I follow the guide at gtidocs.virutotal.com/docs/gti4sentinel-guide API KEY is correct. PS: I'm using standard free public API (created in Viru Total) Managed Identitity has been configured using the correct role. When I run the Logic APP, I received an HTTP error 403 "code": "ForbiddenError", "message": "You are not authorized to perform the requested operation" What's the problem ?? Regards, HATable Talk: Sentinel’s New ThreatIntel Tables Explained
Key updates On April 3, 2025, we publicly previewed two new tables to support STIX (Structured Threat Information eXpression) indicator and object schemas: ThreatIntelIndicators and ThreatIntelObjects. To summarize the important dates: 31 August 2025: We previously announced that data ingestion into the legacy ThreatIntelligenceIndicator table would cease on the 31 July 2025. This timeline has now been extended and the transition to the new ThreatIntelIndicators and ThreatIntelObjects tables will proceed gradually until the 31 st of August 2025. The legacy ThreatIntelligenceIndicator table (and its data) will remain accessible, but no new data will be ingested there. Therefore, any custom content, such as workbooks, queries, or analytic rules, must be updated to reference the new tables to remain effective. If you require additional time to complete the transition, you may opt into dual ingestion, available until the official retirement on the 21 st of May 2026, by submitting a service request. Update: The opt in to dual ingestion ended on the 31 st of August and is no longer available. 31 May 2026: ThreatIntelligenceIndicator table support will officially retire, along with ingestion for those who opt-in to dual ingestion beyond 31 st of August 2025. What’s changing: ThreatIntelligenceIndicator VS ThreatIntelIndicators and ThreatIntelObjects Let’s summarise some of the differences. ThreatIntelligenceIndicator ThreatIntelIndicators ThreatIntelObjects Status Extended data ingestion until the 31st of August 2025, opt-in for additional transition time available. Deprecating on the 31st of May 2026 — no new data will be ingested after this date. Active and recommended for use. Active and complementary to ThreatIntelIndicators. Purpose Originally used to store threat indicators like IPs, domains, file hashes, etc. Stores individual threat indicators (e.g. IPs, URLs, file hashes). Stores STIX objects that provide contextual information about indicators. Examples: threat actors, malware families, campaigns, attack patterns. Characteristics Limitations: o Less flexible schema. o Limited support for STIX (Structured Threat Information eXpression) objects. o Fewer contextual fields for advanced threat hunting. Enhancements: o Supports STIX indicator schema. o Includes a Data column with full STIX object data for advanced hunting. o More metadata fields (e.g. LastUpdateMethod, IsDeleted, ExpirationDateTime). o Optimized ingestion: excludes empty key-value pairs and truncates long fields over 1,000 characters. Enhancements: o Enables richer threat modelling and correlation. o Includes fields like StixType, Data.name, and Data.id. Use cases Legacy structure for storing threat indicators. Migration Note: All custom queries, workbooks, and analytics rules referencing this table must be updated to use the new tables . Ideal for identifying and correlating specific threat indicators. Threat Hunting: Enables hunting for specific Indicators of Compromise (IOCs) such as IP addresses, domains, URLs, and file hashes. Alerting and detection rules: Can be used in KQL queries to match against telemetry from other tables (e.g. Heartbeat, SecurityEvent, Syslog). Example query correlating threat indictors with threat actors: Identify threat actors associated with specific threat indicators Useful for understanding relationships between indicators and broader threat entities (e.g. linking an IP to a known threat actor). Threat Hunting: Adds context by linking indicators to threat actors, malware families, campaigns, and attack patterns. Alerting and Detection rules: Enrich alerts with context like threat actor names or malware types. Example query listing TI objects related to a threat actor, “Sangria Tempest.” : List threat intelligence data related to a specific threat actor Benefits of the new ThreatIntelIndicators and ThreatIntelObjects tables In addition to what’s mentioned in the table above. The main benefits of the new table include: Enhanced Threat Visibility More granular and complete representation of threat intelligence. Support for advanced hunting scenarios and complex queries. Enables attribution to threat actors and relationships. Improved Hunting Capabilities Generic parsing of STIX patterns. Support for all valid STIX IoCs, Threat Actors, Identity, and Relationships. Important considerations with the new TI tables Higher volume of data being ingested: o In the legacy ThreatIntelligenceIndicator table, only the IoCs with Domain, File, URL, Email, Network sources were ingested. o The new tables support a richer schema and more detailed data, which naturally increases ingestion volume. The Data column in both tables stores full STIX objects, which are often large and complex. o Additional metadata fields (e.g. LastUpdateMethod, StixType, ObservableKey, etc.) increase the size of each record. o Some fields like description and pattern are truncated if they exceed 1,000 characters, indicating the potential for large payloads. More Frequent Republishing: o Previously, threat intelligence data was republished over a 12-day cycle. Now, all data is republished every 7-10 days (depending on the volume), increasing the ingestion frequency and volume. o This change ensures fresher data but also leads to more frequent ingestion events. o Republishing is identifiable by LastUpdateMethod = "LogARepublisher" in the tables. Optimising data ingestion There are two mechanisms to optimise threat intelligence data ingestion and control costs. Ingestion Rules See ingestion rules in action: Introducing Threat Intelligence Ingestion Rules | Microsoft Community Hub Sentinel supports Ingestion Rules that allow organizations to curate data before it enters the system. In addition, it enables: Bulk tagging, expiration extensions, and confidence-based filtering, which may increase ingestion if more indicators are retained or extended. Custom workflows that may result in additional ingestion events (e.g. tagging or relationship creation). Reduce noise by filtering out irrelevant TI Objects such as low confidence indicators (e.g. drop IoCs with a confidence score of 0), suppressing known false positives from specific feeds. These rules act on TI objects before they are ingested into Sentinel, giving you control over what gets stored and analysed. Data Collection Rules/ Data transformation As mentioned above, the ThreatIntelIndicator and ThreatIntelObjects tables include a “Data” column which contains the full original STIX object and may or may not be relevant for your use cases. In this case, you can use a workspace transformation DCR to filter it out using a KQL query. An example of this KQL query is shown below, for more examples about using workspace transformations and data collection rules: Data collection rules in Azure Monitor - Azure Monitor | Microsoft Learn source | project-away Data A few things to note: o Your threat intelligence feeds will be sending the additional STIX objects data and IoCs, if you prefer not to receive these additional TI data, you can modify the filter out data according to your use cases as mentioned above. More examples are mentioned here: Work with STIX objects and indicators to enhance threat intelligence and threat hunting in Microsoft Sentinel (Preview) - Microsoft Sentinel | Microsoft Learn o If you are using a data collection rule to make schema changes such as dropping the fields, please make sure to modify the relevant Sentinel content (e.g. detection rules, Workbooks, hunting queries, etc.) that are using the tables. o There can be additional cost when using Azure Monitor data transformations (such as when adding extra columns or adding enrichments to incoming data), however, if Sentinel is enabled on the Log Analytics workspace, there is no filtering ingestion charge regardless of how much data the transformation filters. New Threat Intelligence solution pack available A new Threat Intelligence solution is now available in the Content Hub, providing out of the box content referencing the new TI tables, including 51 detection rules, 5 hunting queries, 1 Workbook, 5 data connectors and also includes 1 parser for the ThreatIntelIndicators. Please note, the previous Threat Intelligence solution pack will be deprecated and removed after the transition phase. We recommend downloading the new solution from the Content Hub as shown below: Conclusion The transition to the new ThreatIntelIndicators and ThreatIntelObjects tables provide enhanced support for STIX schemas, improved hunting and alerting features, and greater control over data ingestion allowing organizations to get deeper visibility and more effective threat detection. To ensure continuity and maximize value, it's essential to update existing content and adopt the new Threat Intelligence solution pack available in the Content Hub. Related content and references: Work with STIX objects and indicators to enhance threat intelligence and threat hunting in Microsoft Sentinel Curate Threat Intelligence using Ingestion Rules Announcing Public Preview: New STIX Objects in Microsoft Sentinel
How to exclude IPs & accounts from Analytic Rule, with Watchlist?
We are trying to filter out some false positives from a Analytic rule called "Service accounts performing RemotePS". Using automation rules still gives a lot of false mail notifications we don't want so we would like to try using a watchlist with the serviceaccounts and IP combination we want to exclude. Anyone knows where and what syntax we would need to exlude the items on the specific Watchlist? Query: let InteractiveTypes = pack_array( // Declare Interactive logon type names 'Interactive', 'CachedInteractive', 'Unlock', 'RemoteInteractive', 'CachedRemoteInteractive', 'CachedUnlock' ); let WhitelistedCmdlets = pack_array( // List of whitelisted commands that don't provide a lot of value 'prompt', 'Out-Default', 'out-lineoutput', 'format-default', 'Set-StrictMode', 'TabExpansion2' ); let WhitelistedAccounts = pack_array('FakeWhitelistedAccount'); // List of accounts that are known to perform this activity in the environment and can be ignored DeviceLogonEvents // Get all logon events... | where AccountName !in~ (WhitelistedAccounts) // ...where it is not a whitelisted account... | where ActionType == "LogonSuccess" // ...and the logon was successful... | where AccountName !contains "$" // ...and not a machine logon. | where AccountName !has "winrm va_" // WinRM will have pseudo account names that match this if there is an explicit permission for an admin to run the cmdlet, so assume it is good. | extend IsInteractive=(LogonType in (InteractiveTypes)) // Determine if the logon is interactive (True=1,False=0)... | summarize HasInteractiveLogon=max(IsInteractive) // ...then bucket and get the maximum interactive value (0 or 1)... by AccountName // ... by the AccountNames | where HasInteractiveLogon == 0 // ...and filter out all accounts that had an interactive logon. // At this point, we have a list of accounts that we believe to be service accounts // Now we need to find RemotePS sessions that were spawned by those accounts // Note that we look at all powershell cmdlets executed to form a 29-day baseline to evaluate the data on today | join kind=rightsemi ( // Start by dropping the account name and only tracking the... DeviceEvents // ... | where ActionType == 'PowerShellCommand' // ...PowerShell commands seen... | where InitiatingProcessFileName =~ 'wsmprovhost.exe' // ...whose parent was wsmprovhost.exe (RemotePS Server)... | extend AccountName = InitiatingProcessAccountName // ...and add an AccountName field so the join is easier ) on AccountName // At this point, we have all of the commands that were ran by service accounts | extend Command = tostring(extractjson('$.Command', tostring(AdditionalFields))) // Extract the actual PowerShell command that was executed | where Command !in (WhitelistedCmdlets) // Remove any values that match the whitelisted cmdlets | summarize (Timestamp, ReportId)=arg_max(TimeGenerated, ReportId), // Then group all of the cmdlets and calculate the min/max times of execution... make_set(Command, 100000), count(), min(TimeGenerated) by // ...as well as creating a list of cmdlets ran and the count.. AccountName, AccountDomain, DeviceName, DeviceId // ...and have the commonality be the account, DeviceName and DeviceId // At this point, we have machine-account pairs along with the list of commands run as well as the first/last time the commands were ran | order by AccountName asc // Order the final list by AccountName just to make it easier to go through | extend HostName = iff(DeviceName has '.', substring(DeviceName, 0, indexof(DeviceName, '.')), DeviceName) | extend DnsDomain = iff(DeviceName has '.', substring(DeviceName, indexof(DeviceName, '.') + 1), "")Multi Workspace for Single tenant is now in Public Preview in Microsoft’s unified SecOps platform
We are excited to continue to expand the use cases addressed with our unified SecOps platform, which brings the capabilities of Microsoft Sentinel, Defender XDR, Security Copilot, Threat Intelligence and more into a single experience with new and more robust functionality. Now, customers can onboard and manage multiple workspaces across Microsoft Sentinel and Defender in one place. Key Benefits of Multi Workspace Experience The multi-workspace experience offers several key benefits that enhance security operations: Unified Entity View: Customers can view all relevant entity data from multiple workspaces in a single entity page, facilitating comprehensive investigations. Workspace Filtering: Users can filter data by workspace when needed, ensuring flexibility in investigations. Enhanced Context: Aggregates alerts, incidents, and timeline events from all workspaces, providing deeper insights into entity behavior. Introducing the Primary Workspace Concept A new concept in the unified SecOps platform is Primary Workspace, which acts as a central hub where Microsoft Sentinel alerts are correlated with XDR data, resulting in incidents that include both Microsoft Sentinel’s primary workspace and XDR alerts. All XDR alerts and incidents are synced back to this workspace, ensuring a cohesive and comprehensive view of security events. The XDR connector is automatically connected to the Primary Workspace upon onboarding and can be switched if necessary. One Primary Workspace must always be connected to use the unified platform effectively. Other onboarded workspaces are considered “Secondary” workspaces, with incidents created based on their individual data. We respect and protect your data boundaries- each workspace’s data will be synced with its own alerts only. Learn more: https://aka.ms/primaryWorkspace Multi Workspace Experience- Key Scenarios Onboarding multiple workspaces to the unified SecOps platform: Open the security portal: https://security.microsoft.com/ There are two options to connect workspaces, you can select either one: Option A: Connecting the workspace through the main home page: Click on” Connect a workspace” in the banner Select the workspaces you wish to onboard and click on “Next”. Select primary workspace Review the text and click on “Connect” After completing the connection, click on “Close”. Option B: Connecting the workspaces through the Settings page: Navigate to Settings and choose “Microsoft Sentinel” Click on "Connect workspace" Follow the same steps as Option A. Switching Primary Workspaces Navigate to Settings and choose "Microsoft Sentinel" On the workspace you wish to assign as Primary, click on the "3 dots" and choose "Set as primary" Confirm and proceed. Incidents and Alerts The incident queue is a single place for a SOC analyst to manage and investigate incidents. The alert queue centralized all your workspaces’ alert in the same place and provides the ability to see the alert page. In the unified queues, you are able now to view all incidents and alerts from all workloads and all workspaces and also filter by workspace. Each alert and incident are related to a single workspace to keep data boundaries. Bi-directional sync: Any change in the unified secOps portal is reflected to Sentinel portal and vice versa. Unified Entities The multi workspace aggregated view enhances entity pages in the unified portal by consolidating data from all relevant Sentinel workspaces into a single, unified experience. This feature enables security teams to gain a complete view of entity-related data without switching between workspaces, improving investigation efficiency and data accessibility. The unified entity page grants you with: Unified Entity View: Customers can see all relevant entity data from multiple workspaces in a single entity page. Workspace Filtering: Users can filter data by workspace when needed, ensuring flexibility in investigations. Enhanced Context: Aggregates alerts, incidents, and timeline events from all workspaces, providing deeper insights into entity behavior. Aggregated view: Provides a unified view of entity data across all workspaces. Supports a predefined logic to display key entity values across components. Introduces workspace filtering in Timeline, Incidents & Alerts, and Insights tabs. Entity Page Enhancements: Overview Section: Displays entity metadata aggregated from all workspaces. Timeline View: Supports events from all workspaces with workspace-based filtering. Incidents & Alerts: Aggregates incidents and alerts from multiple workspaces. Sentinel Tab: Defaults to the primary workspace but allows workspace filtering. Side Pane: Provides a summary view, dynamically updating based on workspace data. Advanced Hunting In Advanced Hunting, you'll be able to explore all your security data in a single place. For hunting and investigation purposes, you'll be able to: Query all Microsoft Sentinel workspaces data. Run queries across multiple workspaces using workspace operator. Access all Logs content of the workspace, including queries and functions, for read/ query Create custom detections on primary workspace Create Analytic rule with workspace operator on a secondary workspace. Microsoft Sentinel features + Using Workspace selector After you connect your workspace to the unified portal, Microsoft Sentinel is on the left-hand side navigation pane. Many of the existing Microsoft Sentinel features are integrated into the unified portal and are similar. Workspace selector: for users with permissions to multiple workspaces, in each Sentinel page, a workspace selector is added to the toolbox. User can easily switch between workspaces using the selector by clicking on “Select a workspace”. SOC Optimization The SOC Optimization feature is also available in the unified portal and contains data and recommendations for multiple workspaces. FAQ Who can onboard multiple workspaces? To onboard a primary workspace, user must be: Global admin/ Security admin AND Owner of subscription OR Global admin/ Security admin AND User access admin AND Microsoft Sentinel contributor To onboard secondary workspaces, user must be Owner of subscription OR User access admin and Microsoft Sentinel contributor. Who can change the primary workspace? Global admin or security admin can change workspace type (Primary/ Secondary) Do I need to onboard all my workspaces? You don’t need to onboard all your workspaces to use this feature, although we highly recommend you to, to ensure full coverage across all your environment. Will all users in my organization have access to all workspaces in the unified security operations portal? No - we respect the permissions granted for each user. Users can see only the data from the workspace they have permissions to. Will data from one workspace be synced to a second workspace? No, we keep the data boundaries between workspaces and ensure that each workspace will only be synced with its own data. When will multi-tenancy be available? Multi-tenancy in the unified SecOps platform for single workspace is already in GA. Multi-tenancy for multiple workspaces is released to public preview with this capability as well. Can I still access my environment in Azure? Yes, all experiences remain the same. We provide bi-directional sync to make sure all changes are up to date. Conclusion Microsoft’s unified SecOps platform support for multi workspace customers represents a significant leap forward in cybersecurity management. By centralizing operations and providing robust tools for detection, investigation, and automation, it empowers organizations to maintain a vigilant and responsive security posture. The platform’s flexibility and comprehensive view of security data make it an invaluable asset for modern security operations. With the public preview now available, organizations can experience firsthand the transformative impact of the Unified Security Operations Platform. Join us in pioneering a new era of cybersecurity excellence. Learn More Please visit our documentation to learn more on the scenarios supported and how to onboard multiple workspaces to the unified platform: https://aka.ms/OnboardMultiWS
Log Analytics Workspace - ThreatIntelIndicators
Morning! I have been working on migrating some of our tenant analytic rules to use the new TI ThreatIntelIndicators table. However, I noticed the following: When querying against the new table, I get these values in a tenant log workspace When I do the same query in another tenant logs workspace, I get this result back If I expand the query to grab last 7 days, I get results back but they are wildly different from what I see from one tenant to another. I can find big and small discrepancies in the logs I see. I still can't find the connector on the connectors page (When I filter them out by data type). I can see the one that is being used for the soon to be decommissioned table. As far as I understand, the connector is not going to be changed per se, just how we access the logs from any given log analytics workspace. I'm expecting to see the same values across my log workspaces since it comes from the same connector, and provided by MS, or is this ingestion of TI logs tenant scope and each one has different settings? I couldn't find something that tells me this in the docs. Or is this part of the rollout problems we are expecting to see? Thanks!Generic Logic App to ingest IOCs in text format
Hi all, I configured Sentinel to ingest IOC from different Threat Intelligence sources (free) using TAXII connector. I would like to ingest others feeds in text format (like https://raw.githubusercontent.com/openphish/public_feed/refs/heads/main/feed.txt, , https://bazaar.abuse.ch/export/txt/sha1/recent/ ) using a generic Logic App to Security Graph. These IOCs could be IP, Hash, URL or domain. Does this kind of Logic App exists ?? Regards, HA
Microsoft Sentinel & Cyberint Threat Intel Integration Guide
Explore comprehensive guide on "Microsoft Sentinel & Cyberint Threat Intel Integration Guide," to learn how to integrate Cyberint's advanced threat intelligence with Microsoft Sentinel. This detailed resource will walk you through the integration process, enabling you to leverage enriched threat data for improved detection and response. Elevate your security posture and ensure robust protection against emerging threats. Read the guide to streamline your threat management and enhance your security capabilities.
