Automating Phishing Email Triage with Microsoft Security Copilot
This blog details automating phishing email triage using Azure Logic Apps, Azure Function Apps, and Microsoft Security Copilot. Deployable in under 10 minutes, this solution primarily analyzes email intent without relying on traditional indicators of compromise, accurately classifying benign/junk, suspicious, and phishing emails. Benefits include reducing manual workload, improved threat detection, and (optional) integration seamlessly with Microsoft Sentinel – enabling analysts to see Security Copilot analysis within the incident itself. Designed for flexibility and control, this Logic App is a customizable solution that can be self-deployed from GitHub. It helps automate phishing response at scale without requiring deep coding expertise, making it ideal for teams that prefer a more configurable approach and want to tailor workflows to their environment. The solution streamlines response and significantly reduces manual effort. Access the full solution on the Security Copilot Github: GitHub - UserReportedPhishing Solution. For teams looking for a more sophisticated, fully integrated experience, the Security Copilot Phishing Triage Agent represents the next generation of phishing response. Natively embedded in Microsoft Defender, the agent autonomously triages phishing incidents with minimal setup. It uses advanced LLM-based reasoning to resolve false alarms, enabling analysts to stay focused on real threats. The agent offers step-by-step decision transparency and continuously learns from user feedback. Read the official announcement here. Introduction: Phishing Challenges Continue to Evolve Phishing continues to evolve in both scale and sophistication, but a growing challenge for defenders isn't just stopping phishing, it’s scaling response. Thanks to tools like Outlook’s "Report Phishing" button and increased user awareness, organizations are now flooded with user-reported emails, many of which are ambiguous or benign. This has created a paradox: better detection by users has overwhelmed SOC teams, turning email triage into a manual, rotational task dreaded for its repetitiveness and time cost, often taking over 25 minutes per email to review. Our solution addresses that problem, by automating the triage of user-reported phishing through AI-driven intent analysis. It's not built to replace your secure email gateways or Microsoft Defender for Office 365; those tools have already done their job. This system assumes the email: Slipped past existing filters, Was suspicious enough for a user to escalate, Lacks typical IOCs like malicious domains or attachments. As a former attacker, I spent years crafting high-quality phishing emails to penetrate the defenses of major banks. Effective phishing doesn't rely on obvious IOCs like malicious domains, URLs, or attachments… the infrastructure often appears clean. The danger lies in the intent. This is where Security Copilot’s LLM-based reasoning is critical, analyzing structure, context, tone, and seasonal pretexts to determine whether an email is phishing, suspicious, spam, or legitimate. What makes this novel is that it's the first solution built specifically for the “last mile” of phishing defense, where human suspicion meets automation, and intent is the only signal left to analyze. It transforms noisy inboxes into structured intelligence and empowers analysts to focus only on what truly matters. Solution Overview: How the Logic App Solution Works (and Why It's Different) Core Components: Azure Logic Apps: Orchestrates the entire workflow, from ingestion to analysis, and 100% customizable. Azure Function Apps: Parses and normalizes email data for efficient AI consumption. Microsoft Security Copilot: Performs sophisticated AI-based phishing analysis by understanding email intent and tactics, rather than relying exclusively on predefined malicious indicators. Key Benefits: Rapid Analysis: Processes phishing alerts and, in minutes, delivers comprehensive reports that empower analysts to make faster, more informed triage decisions – compared to manual reviews that can take up to 30 minutes. And, unlike analysts, Security Copilot requires zero sleep! AI-driven Insights: LLM-based analysis is leveraged to generate clear explanations of classifications by assessing behavioral and contextual signals like urgency, seasonal threats, Business Email Compromise (BEC), subtle language clues, and otherwise sophisticated techniques. Most importantly, it identifies benign emails, which are often the bulk of reported emails. Detailed, Actionable Reports: Generates clear, human-readable HTML reports summarizing threats and recommendations for analyst review. Robust Attachment Parsing: Automatically examines attachments like PDFs and Excel documents for malicious content or contextual inconsistencies. Integrated with Microsoft Sentinel: Optional integration with Sentinel ensures central incident tracking and comprehensive threat management. Analysis is attached directly to the incident, saving analysts more time. Customization: Add, move, or replace any element of the Logic App or prompt to fit your specific workflows. Deployment Guide: Quick, Secure, and Reliable Setup The solution provides Azure Resource Manager (ARM) templates for rapid deployment: Prerequisites: Azure Subscription with Contributor access to a resource group. Microsoft Security Copilot enabled. Dedicated Office 365 shared mailbox (e.g., phishing@yourdomain.com) with Mailbox.Read.Shared permissions. (Optional) Microsoft Sentinel workspace. Refer to the up to date deployment instructions on the Security Copilot GitHub page. Technical Architecture & Workflow: The automated workflow operates as follows: Email Ingestion: Monitors the shared mailbox via Office 365 connector. Triggers on new email arrivals every 3 minutes. Assumes that the reported email has arrived as an attachment to a "carrier" email. Determine if the Email Came from Defender/Sentinel: If the email came from Defender, it would have a prepended subject of “Phishing”, if not, it takes the “False” branch. Change as necessary. Initial Email Processing: Exports raw email content from the shared mailbox. Determines if .msg or .eml attachments are in binary format and converts if necessary. Email Parsing via Azure Function App: Extracts data from email content and attachments (URLs, sender info, email body, etc.) and returns a JSON structure. Prepares clean JSON data for AI analysis. This step is required to "prep" the data for LLM analysis due to token limits. Click on the “Parse Email” block to see the output of the Function App for any troubleshooting. You'll also notice a number of JSON keys that are not used but provided for flexibility. Security Copilot Advanced AI Reasoning: Analyzes email content using a comprehensive prompt that evaluates behavioral and seasonal patterns, BEC indicators, attachment context, and social engineering signals. Scores cumulative risk based on structured heuristics without relying solely on known malicious indicators. Returns validated JSON output (some customers are parsing this JSON and performing other action). This is where you would customize the prompt, should you need to add some of your own organizational situations if the Logic App needs to be tuned: JSON Normalization & Error Handling: A “normalization” Azure Function ensures output matches the expected JSON schema. Sometimes LLMs will stray from a strict output structure, this aims to solve that problem. If you add or remove anything from the Parse Email code that alters the structure of the JSON, this and the next block will need to be updated to match your new structure. Detailed HTML Reporting: Generates a detailed HTML report summarizing AI findings, indicators, and recommended actions. Reports are emailed directly to SOC team distribution lists or ticketing systems. Optional Sentinel Integration: Adds the reasoning & output from Security Copilot directly to the incident comments. This is the ideal location for output since the analyst is already in the security.microsoft.com portal. It waits up to 15 minutes for logs to appear, in situations where the user reports before an incident is created. The solution works pretty well out of the box but may require some tuning, give it a test. Here are some examples of the type of Security Copilot reasoning. Benign email detection: Example of phishing email detection: More sophisticated phishing with subtle clues: Enhanced Technical Details & Clarifications Attachment Processing: When multiple email attachments are detected, the Logic App processes each binary-format email sequentially. If PDF or Excel attachments are detected, they are parsed for content and are evaluated appropriately for content and intent. Security Copilot Reliability: The Security Copilot Logic App API call uses an extensive retry policy (10 retries at 10-minute intervals) to ensure reliable AI analysis despite intermittent service latency. If you run out of SCUs in an hour, it will pause until they are refreshed and continue. Sentinel Integration Reliability: Acknowledges inherent Sentinel logging delays (up to 15 minutes). Implements retry logic and explicit manual alerting for unmatched incidents, if the analysis runs before the incident is created. Security Best Practices: Compare the Function & Logic App to your company security policies to ensure compliance. Credentials, API keys, and sensitive details utilize Azure Managed Identities or secure API connections. No secrets are stored in plaintext. Azure Function Apps perform only safe parsing operations; attachments and content are never executed or opened insecurely. Be sure to check out how the Microsoft Defender for Office team is improving detection capabilities as well Microsoft Defender for Office 365's Language AI for Phish: Enhancing Email Security | Microsoft Community Hub.Case Study: Harnessing Copilot for Security in Defending Against Cyberthreats
Get ready to dive into a real-life security incident within Microsoft Defender XDR! In this case study, you’ll take on the role of a security analyst and uncover how Copilot for Security can empower you throughout the investigation. Let’s see how you can tackle cyber threats head-on!Empowering Security Copilot with NL2KQL: Transforming Natural Language into Insightful KQL queries
By leveraging NL2KQL, a powerful framework that translates natural language into KQL queries, Security Copilot makes querying in KQL as intuitive as a conversation. In this article, we’ll explore the story behind NL2KQL, its potential to transform security operations, and why it matters for the future of cybersecurity.How to Get Started with Copilot in Microsoft Dataverse
Discover the power of Microsoft Dataverse and Copilot in this comprehensive guide. Learn to leverage Copilot's capabilities for seamless table creation and modification. Explore UI differences, understand how to upload Excel files to Dataverse effortlessly, and gain insights into auditing company employee records. Unlock the full potential of these tools for streamlined workflows and efficient data management. Dive into our step-by-step tutorial now!Smarter Prompts for Smarter Investigations: Dynamic Prompt Suggestions in Security Copilot
When a security analyst turns to an AI system for help—whether to hunt threats, investigate alerts, or triage incidents—the first step is usually a natural language prompt. But if that prompt is too vague, too general, or not aligned with the system’s capabilities, the response won’t be helpful. In high-stakes environments like cybersecurity, that’s not just a missed opportunity, it’s a risk. That’s exactly the problem we tackled in our recent paper, Dynamic Context-Aware Prompt Recommendations for Domain-Specific Applications, now published and deployed as a new skill in Security Copilot. Why Prompting Is a Bigger Problem in Security Than It Seems LLMs have made impressive progress in general-purpose settings—helping users write emails, summarize documents, or answer trivia. These systems often include smart prompt recommendations based on the flow of conversation. But when you shift into domain-specific systems like Microsoft Security Copilot, the game changes. Security analysts don’t ask open-ended questions. They ask task-specific ones: “List devices that ran a malicious file in the last 24 hours.” “Correlate failed login attempts across services.” “Visualize outbound traffic from compromised machines.” These questions map directly to skills—domain-specific functions that query data, connect APIs, or launch workflows. And that means prompt recommendations need to be tightly aligned with the available skills, underlying datasets, and current investigation context. General-purpose prompt systems don’t know how to do that. What Makes Domain-Specific Prompting Hard Designing prompt recommendations for systems like Security Copilot comes with unique constraints: Constrained Skill Set: The AI can only take actions it’s configured to support. Prompts must align with those skills—no hallucinations allowed. Evolving Context: A single investigation might involve multiple rounds of prompts, results, follow-ups, and pivots. Prompt suggestions must adapt dynamically. Deep Domain Knowledge: It’s not enough to suggest “Check network logs.” A useful prompt needs to reflect how real analysts work—across Defender, Sentinel, and more. Scalability: As new skills are added, prompt systems must scale without requiring constant manual curation or rewriting. Our Approach: Dynamic, Context-Aware, and Skill-Constrained We introduce a dynamic prompt recommendation system for Security Copilot. The key innovations include: Contextual understanding of the session: We track the user’s investigation path and surface prompts that are relevant to what they’re doing now, not just generic starters. Skill-awareness: The system knows what internal capabilities exist (e.g., “list devices,” “query login events”) and only recommends prompts that can be executed via those skills. Domain knowledge injection: By encoding metadata about products, datasets, and typical workflows (e.g., MITRE attack stages), the system produces prompts that make sense in security analyst workflows. Scalable prompt generation: Rather than relying on hardcoded lists, our system dynamically generates and ranks prompt suggestions. What It Looks Like in Action The dynamic prompt suggestion system is now live in Microsoft Entra, available in both Embedded and Immersive experiences. When a user enters a natural language prompt, the system automatically suggests several context-aware follow-up prompts, based on the user's prior interactions and the system’s understanding of the current task. These suggestions are generated in real time—users can simply click on a suggestion, and it’s executed immediately, allowing for quick and seamless follow-up queries without needing to rephrase or retype. Let’s walk through two examples: Embedded Experience We begin with the prompt: "How does Microsoft determine Risky Users?" The system returns the response and generates 3 follow-up suggestions, such as: "List dismissed risky detections." We click on that suggestion, which executes the query and shows the results. New suggestions continue to appear after each prompt execution, making it easy to explore related insights. Immersive Experience We start with a prompt: "Who am I?" Among the 5 suggested prompts, we select: "List the groups user nase74@woodgrove.ms is a member of." The user clicks, the query runs, and more follow-up suggestions appear, enabling a natural, guided flow throughout the session. Why This Matters for the Future of Security AI Prompting isn’t just an interface detail—it’s the entry point to intelligence. And in cybersecurity, where time, accuracy, and reliability matter, we need AI systems that are not just capable, but cooperative. Our research contributes to a future where security analysts don’t have to be prompt engineers to get the most out of AI. By making prompt recommendations dynamic, contextual, and grounded in real domain knowledge, we help close the gap between LLM potential and security reality. Interested in learning more? Check out the full paper: Dynamic Context-Aware Prompt Recommendations for Domain-Specific Applications If you're using or building upon this work in your own research, we’d appreciate you citing our paper: @article {tang2025dynamic, title={Dynamic Context-Aware Prompt Recommendation for Domain-Specific AI Applications}, author={Tang, Xinye and Zhai, Haijun and Belwal, Chaitanya and Thayanithi, Vineeth and Baumann, Philip and Roy, Yogesh K}, journal={arXiv preprint arXiv:2506.20815}, year={2025} }Next-Gen Device Incident Investigation & Threat Hunting with Custom Plugins
The Security Copilot custom plugin empowers you to extend Security Copilot functionalities beyond the preinstalled and third-party plugins. This blog introduces two custom plugins that you can install and use in your environment. An incident investigation case study will be used to demonstrate the features of these two custom plugins. Additionally, a step-by-step guide will walk you through the setup process, which only takes a few clicks. The first custom plugin, “Custom Plugin Defender Device Investigation”, provides the following skills: Title: File - Files Downloaded Description: Lists files downloaded to this device in specific timeframe within past 30 days. Title: File - Last 15 Days Files Downloaded Description: Lists files downloaded to this device in the last 15 days. Title: File - Any Device Events Related To This File Description: Display device events that include the filename, in specific timeframe. Title: File - Sensitive Files Events Description: Lists sensitive files events on this device in the last 10 days. Title: File - File Origin Description: Display the origin or source of the file, in past 30 days. Title: Process - Process Executions Summary Description: Summary of process executions on this device in specific timeframe. Title: Process - Detailed Process Executions Description: Detailed all process execution events on device within a brief period, e.g. an hour. Title: Process - Detailed Process Events Description: Detailed specific process execution events on device within a defined time frame. Title: Lateral Movement - RDP To Device Description: Inbound RDP connection to this device in a specific timeframe. Title: Lateral Movement - Logon To Device Description: Logon events from other devices to this device in a specific timeframe. Title: Lateral Movement - Logons To Device In Last 10 Days Description: Logon events from other devices to this device in the last 10 days. Title: Network - Outbound Network Events Description: Device outbound network events, including attempts and failed connections. Title: Network - Inbound Network Events Description: Device inbound network events and attempts in a specific timeframe. Title: Network - Device Listening Ports Description: Displays device listening ports in specific timeframe. Title: Device Events - Scheduled Task Events Description: Scheduled task events seen on a device in a specific timeframe. Title: Device Events - User Account Events Description: User account events seen on a device in a specific timeframe. Title: Device Events - User Account Added Or Removed From Local Group Description: User account added or removed from local group in a specific timeframe. Title: Suspicious Activities - ASR Rules Triggered Description: ASR rules that were triggered on this device in the past 7 days. Title: Suspicious Activities - ASMSI Script Detection Description: Script detection from Windows Antimalware Scan Interface (AMSI) in past 7 days. Title: Suspicious Activities - Exploit Guard Events Description: Exploit Guard events detected on this device in past 7 days. Title: Suspicious Activities - Network Protection Events Description: Network Protection events triggered on this device in the past 7 days. Title: Suspicious Activities - Device Tampering Attempts Description: Possible tampering attempts on this device in the past 7 days. The second custom plugin, “Custom Plugin Defender Device Info”, offers specific device information often needed during an investigation. Its skills include: Title: Device OS Information Description: Latest device OS information with the device name as the input. Title: Device Current and Past IPs Description: The current and past IPs assigned to this device in the last 10 days. Title: Device Users and Login Counts Description: List users logged onto this device and the number of times, within the last 10 days. Title: Device Alert Information Description: Alerts observed on this device in the last 30 days. Title: Device Installed Applications Description: Currently installed applications on this device. Title: Device Vulnerability Information Description: Vulnerabilities identified on this device. Title: Device Critical Vulnerabilities Description: Vulnerability with CVSS score 7 or higher, or exploit is publicly available. Both custom plugins are available for download from the Security Copilot GitHub repository at this link. Step-by-step guides on how to install the custom plugin will be covered later in this blog. Let's start by demonstrating some of the capabilities of the two custom plugins through a case study of a Microsoft Defender XDR incident. For this incident, the Security Copilot incident summary reveals that the threat actor used a credential phishing attack to gain initial access. Over the course of the incident, several instances of lateral movement, credential access, and privilege escalation were detected, impacting users and devices across the network. Key activities included the use of tools like Mimikatz and Rubeus, suspicious remote sessions, and evidence of system manipulation. From the Security Copilot incident summary, you learn that the attack started when user “jonaw” clicked on a malicious URL in an email. Following that, a suspicious remote session was detected on device “vnevado-win10v”. To investigate the suspicious remote session on the device, one way is to leverage the “Lateral Movement – Logon To Device” skill from the “Custom Plugin Defender Device Investigation” plugin in Security Copilot's standalone mode. This skill presents the logon events that occurred on the device within the specified timeframe. The logon events include console logons, Remote Desktop logons, remote registry logons, scheduled task logons, and more. You can invoke this skill by navigating to the System Capabilities menu option from the prompt bar. To get to the System Capabilities menu option, select the Prompts option from the prompt bar, as shown next. Then the System Capabilities menu option appears. This skill is located under the plugin named “CUSTOM PLUGIN DEFENDER DEVICE INVESTIGATION”, as shown next. Once this skill is selected, you will need to fill in three input fields: the device name, start time, and end time. For this case study, the alert for the suspicious remote session was triggered for device vnevado-win10v, occurring at approximately 9:42 UTC on November 22 nd 2024. For the investigation, let's set the start time to 2024-11-22 9:30 UTC and the end time to 9:50 UTC, as shown in the next screenshot. The next screenshot demonstrates that Security Copilot executes this skill. Using the “Export to Excel” option in the Copilot response, you can download then manually review the logon events. Upon inspection, it is discovered that for device vnevado-win10v, there is a long list of logon events involving different user accounts within the 20-minute time frame. A screenshot showing a portion of the logon events is displayed next. You can then ask Security Copilot with this prompt: “Can you review the previous output of the logon events for the device vnevado-win10v between 2024-11-22 09:30 and 2024-11-22 09:50, summarize the logon events and also point out anything suspicious”. The next screenshot displays the Security Copilot prompt along with the beginning of its response. The logon event summary provided by Security Copilot is thorough but a bit long. At the end, it includes the identified suspicious logon activities: There are several instances where logon attempts are followed by successful logons within milliseconds, which could indicate automated or scripted logon attempts. There are 10 logon events with an "Unknown" logon type, which is unusual and may warrant further investigation. The account debrab has one logon event where it is marked as a local admin, which should be verified for legitimacy. For your reference, the last section of the Security Copilot’s logon event summary is shown in the next screen capture. After reviewing the logon event summary for device vnevado-win10v, let’s find out who might be the owner of this device. The “Device Users and Login Counts” skill from the “Custom Plugin Defender Device Info” plugin provides a summary of how many times each user has logged into the device over the past 30 days. Typically, the user with the most logins is likely the device owner. Once the skill is executed for device vnevado-win10v, Security Copilot reports that “user jonaw has logged onto the device vnevado-win10v a total of 189 times in the last 30 days”, as shown in the next screen capture. This helps to identify user “jonaw” as the likely device owner, which in turn makes user “debrab” appear even more suspicious. Let’s go back to the detailed logon events provided by Security Copilot earlier and take another look at user account “debrab”. The next screenshot shows the logon events for device vnevado-win10v, filtered to display only those associated with the user “debrab”. One notable observation is that the logon type for user “debrab” is either batch or unknown, which appears suspicious as well, especially with one batch logon with local admin privilege. What is a batch logon type? You can ask Security Copilot for more insights. The next screenshot displays Copilot’s responses, which explains that a batch logon type is typically used for scheduled tasks. The batch logon seems odd in this case. One of Security Copilot's key features is its ability to distinguish between normal and anomalous behavior in IT operations. In this case, let’s ask Security Copilot whether it’s common for someone with local admin privilege to log on to a device through a batch logon. As seen in the previous screenshot, Security Copilot points out that the batch logon is unusual, as it is typically used for scheduled tasks or automated processes, not for interactive sessions by administrators. Security Copilot’s response further confirms that the batch logon events with user account “debrab” are suspicious. This information and the other Security Copilot observations can assist you in identifying the suspicious remote session detected on device “vnevado-win10v”. The incident summary generated by Security Copilot not only mentions the detection of a suspicious remote session on device vnevado-win10v, but also reports the presence of suspicious files, including mimikatz.exe, rubeus.exe, xcopy.exe, and powershell.exe. The incident summary snippet is displayed next for reference. Let’s now examine what occurred on the device involving these suspicious files. A quick and easy way to start the investigation is to check for files downloaded to the device and reviewing the device's process execution events around the time of the incident to identify anything suspicious. Manually checking for downloaded files and examining process execution events can be time-consuming and labor-intensive. However, with the help of Security Copilot, these tasks can be performed more quickly and efficiently. The “File - Files Downloaded” skill from the “Custom Plugin Defender Device Investigation” plugin can be used to quickly identify files that were downloaded onto a device within a specific time period. Then, the “Process - Process Executions Summary” skill from the same Security Copilot plugin can be used to list the processes that executed on the device during the same timeframe. You can then ask Security Copilot to analyze these processes to identify anything suspicious. After the “File - Files Downloaded” skill executes, Security Copilot identifies a file named DomainDominance198.zip was downloaded to device vnevado-win10v. Another thing to keep in mind is that not all the information from the Copilot findings is directly visible in the Security Copilot console. You can expand the output result within the console or export the findings to Excel for a clearer view of the additional details. For this investigation, you can then more thoroughly review the URL from which the file was downloaded, verify the file location through its folder path, and locate the user account associated with the download. The next screenshot displays these additional details seen in the Excel spreadsheet. Then, the “Process - Process Executions Summary” skill provides a list of processes executed on the same device, vnevado-win10v, during the same period. Instead of manually reviewing all 128 processes, you can ask Security Copilot to analyze the processes and flag any suspicious ones. In addition, it's worth mentioning earlier in the investigation, leveraging the Microsoft Entra plugin, Security Copilot reports that user account “jonaw” belongs to Jonathan Wolcott, an account executive in the Sales department. With this information, let’s ask Security Copilot to identify any process execution that should typically not be carried out by someone outside of the IT department. Here is the Security Copilot prompt you can use: User “jonaw” is an account executive in the sales department, with this information, can you identify any processes that typically should not be carried out by someone outside of the IT department? Security Copilot then identifies six suspicious processes and provides its reasoning along the way. Once again, you can export the Security Copilot findings to Excel for a more thorough review. The next screenshot displays the results in Excel, with a more readable format. Now that a few more suspicious processes have been identified, let's revisit the downloaded file, DomainDominance198.zip, to see if more details can be uncovered. The skill, “File - Any Device Events Related To This File”, is part of the “Custom Plugin Defender Device Investigation” plugin in Security Copilot. It is designed to identify any device events or activities related to a specific file. It uses the filename as a keyword to filter and display only the device events containing this keyword within a defined time period. For this security incident, let's use this skill to search for device events containing the name of the downloaded file, DomainDominance198. Upon reviewing the Security Copilot response exported to Excel, you can see that a new file, DomainDominance198.ps1, has been created in the same directory as DomainDominance198.zip. In addition, the “File - File Origin” skill in the “Custom Plugin Defender Device Investigation” plugin provides details about a file's origin or source. It shows where the file came from, and any associated file or connection linked to it. In this case, as shown in the next screenshot, Security Copilot reveals that the file DomainDominance198.zip was downloaded from a specific URL. And that the file DomainDominance198.ps1 is associated with file DomainDominance198.zip, as shown next. The additional details in Security Copilot’s responses highlight the exact association, indicating that the File Origin Referrer URL for DomainDominance198.ps1 is DomainDominance198.zip, as shown in the next screen capture. With these insights, let's use another Security Copilot skill to conduct a more in-depth examination of PowerShell execution events on device vnevado-win10v. The skill, “Process - Detailed Process Events”, is also part of the “Custom Plugin Defender Device Investigation” plugin. It retrieves detailed process execution events, including process command line information and the parent process execution details, for the specified process on a given device within a defined time frame. When this skill is invoked, it requires four mandatory fields to be filled, as shown next. Security Copilot then displays the PowerShell execution events identified on device vnevado-win10v within the specified timeframe of 2024-11-22 09:30 to 2024-11-22 10:30, as shown next. From a more condensed text view of the responses from Security Copilot, a range of unusual or potentially harmful behaviors can be observed in the next screenshot. Some of these suspicious events are highlighted in yellow or displayed in bold in the next screenshot. The process execution events retrieved include command line details and parent process, therefore you are able to see both the PowerShell execution and processes launched with PowerShell as the parent process. The suspicious processes, such as mimikatz.exe, Rubeus.exe, xcopy.exe, PxExec.exe, and others mentioned in the Security Copilot incident summary, are identified here, allowing you to quickly recognize the correlation. Additionally, you can ask Security Copilot to assist you in reviewing the suspicious events. For instance, immediately after the xcopy command was used to copy the file “Rubeus.exe” to the remote device vnevado-win10b, a subsequent command involving “PsExec.exe” is observed in the detailed PowerShell execution events presented earlier by Security Copilot. The two command lines are shown in the next screen capture. Consulting with Security Copilot reveals that “PsExec.exe” executed a command remotely on the device vnevado-win10b. This command launched “Rubeus.exe” to dump Kerberos tickets for the user “nestorw” and saved the output to C:\Temp\AdminTicket.txt. Security Copilot notes that this action indicates credential dumping and potential lateral movement within the network. The next screenshot shows the prompt along with part of the responses from Security Copilot. As there are many other potentially harmful behaviors also observed in the detailed PowerShell execution events presented by Security Copilot earlier, you can submit each of these suspicious events to Security Copilot and ask for insights. Downloading and Installing the Custom Plugins The configuration files for the custom plugins can be downloaded from this link. Once you have the configuration file (in YAML format), here are the steps to upload and install it to your Security Copilot instance. Step 1: Select the Sources icon in the Prompt bar. Step 2: Scroll to the bottom of the Manage Sources page, within the Custom section, you'll find the "Add a plugin" option. Step 3: Click on “Add plugin” and then choose “Copilot for Security plugin”, as illustrated in the next screenshot. Step 4: Click on “Upload file” to install configuration file, which is in YAML format. Step 5: Click on Add. And voilà, the new custom plugin appears along with other plugins in the Manage sources section, as seen in the screen capture next. Now you can start using the custom plugins and they will appear in the “System Capabilities” section.KQL Migrator powered by Microsoft Security Copilot
Overview A couple of weeks ago, Hesham and Hiten attended an internal Global Blackbelt summit in Redmond. Unfortunately, we encountered bad weather due to a “Bomb Cyclone”. Consequently, many people within the Washington State area were left without essential services such as electricity and running water. The Microsoft Campus was converted into a temporary relief center, leading to the rescheduling of our sessions for the day. Fortunately, we were staying at a hotel equipped with a backup generator, running water, and heating. We borrowed a whiteboard and spent the next few hours discussing the migration from 3 rd party solutions and mainly different query-based languages to Microsoft Sentinel – Defender XDR and KQL (Kusto Query Language) SIEM migrations are always a challenging process that requires meticulous planning and a thorough understanding of the existing setup in the legacy SIEM and what needs to be migrated to the modern SIEM. Our primary discussion point was how we can efficiently assist organizations in translating detection rules from query-based languages like AQL (Ariel Query Languages) to KQL (Kusto Query Language) and to help organizations mainly SOC teams to convert their YARA rules, STIX II and OpenIOC intel to KQL format We identified three options: Convert AQL to KQL Convert YARA to KQL Convert STIX II and OpenIOC intel to KQL All three options require specialized skills and can be cumbersome to complete. For example, the user would need to understand precisely how AQL maps to KQL and second option require through knowledge of the syntax used in YARA generation. Both of these are niche skills, the same also applies to STIX II. One thing to point out here that we are not experts in query language like AQL and YARA Rules, we know how to export the detection rules in CVE format, our combined knowledge of AQL is also limited and would be considered basic at best. We quickly realized that AQL is similar to SQL and consequently KQL. We had the following AQL Code: Select sourceip, destinationip, "Process Name" FROM events WHERE "Process Name" IMATCHES '.*atbroker\.exe.*|.*bash\.exe.*|.*bitsadmin\.exe.*|.*certutil\.exe.*|.*cmdkey\.exe.*|.*cmstp\.exe.*|.*control\.exe.*|.*csc\.exe.*|.*cscript\.exe.*|.*dfsvc\.exe.*|.*diskshadow\.exe.*|.*dnscmd\.exe.*|.*esentutl\.exe.*|.*eventvwr\.exe.*|.*expand\.exe.*|.*extexport\.exe.*|.*extrac32\.exe.*|.*findstr\.exe.*|.*forfiles\.exe.*|.*ftp\.exe.*|.*gpscript\.exe.*|.*hh\.exe.*|.*ie4uinit\.exe.*|.*ieexec\.exe.*|.*infdefaultinstall\.exe.*|.*installutil\.exe.*|.*makecab\.exe.*|.*reg\.exe.*|.*print\.exe.*|.*presentationhost\.exe.*|.*pcwrun\.exe.*|.*pcalua\.exe.*|.*odbcconf\.exe.*|.*msiexec\.exe.*|.*mshta\.exe.*|.*msdt\.exe.*|.*msconfig\.exe.*|.*msbuild\.exe.*|.*mmc\.exe.*|.*microsoft.workflow.compiler\.exe.*|.*mavinject\.exe.*|.*vsjitdebugger\.exe.*|.*tracker\.exe.*|.*te\.exe.*|.*sqltoolsps\.exe.*|.*sqlps\.exe.*|.*sqldumper\.exe.*|.*rcsi\.exe.*|.*msxsl\.exe.*|.*msdeploy\.exe.*|.*mftrace\.exe.*|.*dxcap\.exe.*|.*dnx\.exe.*|.*csi\.exe.*|.*cdb\.exe.*|.*bginfo\.exe.*|.*appvlp\.exe.*|.*xwizard\.exe.*|.*wsreset\.exe.*|.*wscript\.exe.*|.*wmic\.exe.*|.*wab\.exe.*|.*verclsid\.exe.*|.*syncappvpublishingserver\.exe.*|.*scriptrunner\.exe.*|.*schtasks\.exe.*|.*sc\.exe.*|.*runscripthelper\.exe.*|.*runonce\.exe.*|.*rundll32\.exe.*|.*rpcping\.exe.*|.*replace\.exe.*|.*regsvr32\.exe.*|.*regsvcs\.exe.*|.*register-cimprovider\.exe.*|.*regedit\.exe.*|.*regasm\.exe.*|' GROUP BY "Process Name",sourceip LAST 3 DAYS This query aims to track the use of specific executables for administrative or potentially malicious activities. By grouping results by process name and source IP, it helps detect patterns or anomalies that may indicate security incidents or policy violations. Using Microsoft Security Copilot What if we could get Security Copilot to firstly explain the code and then convert it to Kusto? We used the following prompt: /askGPT I am planning a SIEM migration from AQL query based to Microsoft Sentinel KQL. As AQL expert can you create a detailed summary that explains the following AQL query in square brackets [ Select sourceip, destinationip, "Process Name" FROM events WHERE "Process Name" IMATCHES '.*atbroker\.exe.*|.*bash\.exe.*|.*bitsadmin\.exe.*|.*certutil\.exe.*|.*cmdkey\.exe.*|.*cmstp\.exe.*|.*control\.exe.*|.*csc\.exe.*|.*cscript\.exe.*|.*dfsvc\.exe.*|.*diskshadow\.exe.*|.*dnscmd\.exe.*|.*esentutl\.exe.*|.*eventvwr\.exe.*|.*expand\.exe.*|.*extexport\.exe.*|.*extrac32\.exe.*|.*findstr\.exe.*|.*forfiles\.exe.*|.*ftp\.exe.*|.*gpscript\.exe.*|.*hh\.exe.*|.*ie4uinit\.exe.*|.*ieexec\.exe.*|.*infdefaultinstall\.exe.*|.*installutil\.exe.*|.*makecab\.exe.*|.*reg\.exe.*|.*print\.exe.*|.*presentationhost\.exe.*|.*pcwrun\.exe.*|.*pcalua\.exe.*|.*odbcconf\.exe.*|.*msiexec\.exe.*|.*mshta\.exe.*|.*msdt\.exe.*|.*msconfig\.exe.*|.*msbuild\.exe.*|.*mmc\.exe.*|.*microsoft.workflow.compiler\.exe.*|.*mavinject\.exe.*|.*vsjitdebugger\.exe.*|.*tracker\.exe.*|.*te\.exe.*|.*sqltoolsps\.exe.*|.*sqlps\.exe.*|.*sqldumper\.exe.*|.*rcsi\.exe.*|.*msxsl\.exe.*|.*msdeploy\.exe.*|.*mftrace\.exe.*|.*dxcap\.exe.*|.*dnx\.exe.*|.*csi\.exe.*|.*cdb\.exe.*|.*bginfo\.exe.*|.*appvlp\.exe.*|.*xwizard\.exe.*|.*wsreset\.exe.*|.*wscript\.exe.*|.*wmic\.exe.*|.*wab\.exe.*|.*verclsid\.exe.*|.*syncappvpublishingserver\.exe.*|.*scriptrunner\.exe.*|.*schtasks\.exe.*|.*sc\.exe.*|.*runscripthelper\.exe.*|.*runonce\.exe.*|.*rundll32\.exe.*|.*rpcping\.exe.*|.*replace\.exe.*|.*regsvr32\.exe.*|.*regsvcs\.exe.*|.*register-cimprovider\.exe.*|.*regedit\.exe.*|.*regasm\.exe.*|' GROUP BY "Process Name",sourceip LAST 3 DAYS] Below is the OUTPUT Detailed Summary of AQL Query Breakdown Query Overview The provided AQL query is designed to search for specific process names within event logs and return the source and destination IP addresses associated with those processes. Here's a detailed breakdown of the query: AQL Query Breakdown Select Clause: sourceip: The source IP address from which the event originated. destinationip: The destination IP address to which the event was directed. "Process Name": The name of the process involved in the event. From Clause: events: The dataset or table from which the query is retrieving data. Where Clause: "Process Name" IMATCHES '.*atbroker\.exe.*|.*bash\.exe.*|.*bitsadmin\.exe.*|.*certutil\.exe.*|.*cmdkey\.exe.*|.*cmstp\.exe.*|.*control\.exe.*|.*csc\.exe.*|.*cscript\.exe.*|.*dfsvc\.exe.*|.*diskshadow\.exe.*|.*dnscmd\.exe.*|.*esentutl\.exe.*|.*eventvwr\.exe.*|.*expand\.exe.*|.*extexport\.exe.*|.*extrac32\.exe.*|.*findstr\.exe.*|.*forfiles\.exe.*|.*ftp\.exe.*|.*gpscript\.exe.*|.*hh\.exe.*|.*ie4uinit\.exe.*|.*ieexec\.exe.*|.*infdefaultinstall\.exe.*|.*installutil\.exe.*|.*makecab\.exe.*|.*reg\.exe.*|.*print\.exe.*|.*presentationhost\.exe.*|.*pcwrun\.exe.*|.*pcalua\.exe.*|.*odbcconf\.exe.*|.*msiexec\.exe.*|.*mshta\.exe.*|.*msdt\.exe.*|.*msconfig\.exe.*|.*msbuild\.exe.*|.*mmc\.exe.*|.*microsoft.workflow.compiler\.exe.*|.*mavinject\.exe.*|.*vsjitdebugger\.exe.*|.*tracker\.exe.*|.*te\.exe.*|.*sqltoolsps\.exe.*|.*sqlps\.exe.*|.*sqldumper\.exe.*|.*rcsi\.exe.*|.*msxsl\.exe.*|.*msdeploy\.exe.*|.*mftrace\.exe.*|.*dxcap\.exe.*|.*dnx\.exe.*|.*csi\.exe.*|.*cdb\.exe.*|.*bginfo\.exe.*|.*appvlp\.exe.*|.*xwizard\.exe.*|.*wsreset\.exe.*|.*wscript\.exe.*|.*wmic\.exe.*|.*wab\.exe.*|.*verclsid\.exe.*|.*syncappvpublishingserver\.exe.*|.*scriptrunner\.exe.*|.*schtasks\.exe.*|.*sc\.exe.*|.*runscripthelper\.exe.*|.*runonce\.exe.*|.*rundll32\.exe.*|.*rpcping\.exe.*|.*replace\.exe.*|.*regsvr32\.exe.*|.*regsvcs\.exe.*|.*register-cimprovider\.exe.*|.*regedit\.exe.*|.*regasm\.exe.*': This condition filters events to include only those where the process name matches any of the specified patterns. The IMATCHES operator is used for case-insensitive regular expression matching. Group By Clause: "Process Name", sourceip: The results are grouped by the process name and source IP address. Time Range: LAST 3 DAYS: The query is limited to events that occurred within the last three days. Summary This AQL query is designed to identify and group events based on specific process names that are often associated with suspicious or malicious activity. By focusing on these processes, the query helps in monitoring and investigating potential security incidents. The results provide insights into the source and destination IP addresses involved, which can be crucial for further analysis and response. The query returns the process name, source IP, and destination IP for events matching the specified process names, grouped by process name and source IP, within the last three days. This next step to see if Security Copilot can help convert the AQL to something that is mapped to Microsoft Sentinel Kusto Query Language: Can you analyze the AQL query above and map it to KQL, it is important to ensure that the mapping directly correlates to the schema in KQL. Can you also show the output of the query in a table. Present the mappings in a table: KQL Query and Output KQL Query Mapping DeviceProcessEvents | where TimeGenerated >= ago(3d) | where InitiatingProcessFileName matches regex @'(?i).*atbroker\.exe.*|.*bash\.exe.*|.*bitsadmin\.exe.*|.*certutil\.exe.*|.*cmdkey\.exe.*|.*cmstp\.exe.*|.*control\.exe.*|.*csc\.exe.*|.*cscript\.exe.*|.*dfsvc\.exe.*|.*diskshadow\.exe.*|.*dnscmd\.exe.*|.*esentutl\.exe.*|.*eventvwr\.exe.*|.*expand\.exe.*|.*extexport\.exe.*|.*extrac32\.exe.*|.*findstr\.exe.*|.*forfiles\.exe.*|.*ftp\.exe.*|.*gpscript\.exe.*|.*hh\.exe.*|.*ie4uinit\.exe.*|.*ieexec\.exe.*|.*infdefaultinstall\.exe.*|.*installutil\.exe.*|.*makecab\.exe.*|.*reg\.exe.*|.*print\.exe.*|.*presentationhost\.exe.*|.*pcwrun\.exe.*|.*pcalua\.exe.*|.*odbcconf\.exe.*|.*msiexec\.exe.*|.*mshta\.exe.*|.*msdt\.exe.*|.*msconfig\.exe.*|.*msbuild\.exe.*|.*mmc\.exe.*|.*microsoft.workflow.compiler\.exe.*|.*mavinject\.exe.*|.*vsjitdebugger\.exe.*|.*tracker\.exe.*|.*te\.exe.*|.*sqltoolsps\.exe.*|.*sqlps\.exe.*|.*sqldumper\.exe.*|.*rcsi\.exe.*|.*msxsl\.exe.*|.*msdeploy\.exe.*|.*mftrace\.exe.*|.*dxcap\.exe.*|.*dnx\.exe.*|.*csi\.exe.*|.*cdb\.exe.*|.*bginfo\.exe.*|.*appvlp\.exe.*|.*xwizard\.exe.*|.*wsreset\.exe.*|.*wscript\.exe.*|.*wmic\.exe.*|.*wab\.exe.*|.*verclsid\.exe.*|.*syncappvpublishingserver\.exe.*|.*scriptrunner\.exe.*|.*schtasks\.exe.*|.*sc\.exe.*|.*runscripthelper\.exe.*|.*runonce\.exe.*|.*rundll32\.exe.*|.*rpcping\.exe.*|.*replace\.exe.*|.*regsvr32\.exe.*|.*regsvcs\.exe.*|.*register-cimprovider\.exe.*|.*regedit\.exe.*|.*regasm\.exe.*' | summarize by InitiatingProcessFileName Query Output InitiatingProcessFileName csc.exe gpupdate.exe microsoftedgeupdate.exe msiexec.exe schtasks.exe sc.exe cscript.exe rundll32.exe makecab.exe route.exe Row Counts Total Rows: 10 Displayed Rows: 10 Product Name Product: Sentinel The extended team highlighted the importance of considering YARA rules for uniformity. Given that expertise in YARA rule generation was lacking, Security Copilot as again consulted: /askGPT Can you explain what a YAYA rule is with an example A YARA rule is a type of rule used in cybersecurity to identify and classify malware samples. YARA, which stands for "Yet Another Recursive Acronym," is a tool aimed at helping malware researchers identify and classify malware. YARA rules are written in a specific syntax and are used to describe patterns that can be found in files or processes. Example of a YARA Rule Here is a simple example of a YARA rule that detects a file containing the string "malicious": rule ExampleRule { meta: description = "This rule detects files containing the string 'malicious'" author = "Security Researcher" date = "2024-12-09" strings: $malicious_string = "malicious" condition: $malicious_string } So we have a base understand of what a YARA rule is and its typical format. The step is can we use Security Copilot to convert the YARA into a KQL Rule: We used the following prompt: As a YARA rule expert, can you take the above KQL query generated and create a KQL rule? rule Suspicious_Process_Execution { meta: description = "Detects execution of potentially suspicious processes" author = "Security Analyst" date = "2023-10-01" strings: $atbroker = /(?i).*atbroker\.exe.*/ $bash = /(?i).*bash\.exe.*/ $bitsadmin = /(?i).*bitsadmin\.exe.*/ $certutil = /(?i).*certutil\.exe.*/ $cmdkey = /(?i).*cmdkey\.exe.*/ $cmstp = /(?i).*cmstp\.exe.*/ $control = /(?i).*control\.exe.*/ $csc = /(?i).*csc\.exe.*/ $cscript = /(?i).*cscript\.exe.*/ $dfsvc = /(?i).*dfsvc\.exe.*/ $diskshadow = /(?i).*diskshadow\.exe.*/ $dnscmd = /(?i).*dnscmd\.exe.*/ $esentutl = /(?i).*esentutl\.exe.*/ $eventvwr = /(?i).*eventvwr\.exe.*/ $expand = /(?i).*expand\.exe.*/ $extexport = /(?i).*extexport\.exe.*/ $extrac32 = /(?i).*extrac32\.exe.*/ $findstr = /(?i).*findstr\.exe.*/ $forfiles = /(?i).*forfiles\.exe.*/ $ftp = /(?i).*ftp\.exe.*/ $gpscript = /(?i).*gpscript\.exe.*/ $hh = /(?i).*hh\.exe.*/ $ie4uinit = /(?i).*ie4uinit\.exe.*/ $ieexec = /(?i).*ieexec\.exe.*/ $infdefaultinstall = /(?i).*infdefaultinstall\.exe.*/ $installutil = /(?i).*installutil\.exe.*/ $makecab = /(?i).*makecab\.exe.*/ $reg = /(?i).*reg\.exe.*/ $print = /(?i).*print\.exe.*/ $presentationhost = /(?i).*presentationhost\.exe.*/ $pcwrun = /(?i).*pcwrun\.exe.*/ $pcalua = /(?i).*pcalua\.exe.*/ $odbcconf = /(?i).*odbcconf\.exe.*/ $msiexec = /(?i).*msiexec\.exe.*/ $mshta = /(?i).*mshta\.exe.*/ $msdt = /(?i).*msdt\.exe.*/ $msconfig = /(?i).*msconfig\.exe.*/ $msbuild = /(?i).*msbuild\.exe.*/ $mmc = /(?i).*mmc\.exe.*/ $microsoft_workflow_compiler = /(?i).*microsoft\.workflow\.compiler\.exe.*/ $mavinject = /(?i).*mavinject\.exe.*/ $vsjitdebugger = /(?i).*vsjitdebugger\.exe.*/ $tracker = /(?i).*tracker\.exe.*/ $te = /(?i).*te\.exe.*/ $sqltoolsps = /(?i).*sqltoolsps\.exe.*/ $sqlps = /(?i).*sqlps\.exe.*/ $sqldumper = /(?i).*sqldumper\.exe.*/ $rcsi = /(?i).*rcsi\.exe.*/ $msxsl = /(?i).*msxsl\.exe.*/ $msdeploy = /(?i).*msdeploy\.exe.*/ $mftrace = /(?i).*mftrace\.exe.*/ $dxcap = /(?i).*dxcap\.exe.*/ $dnx = /(?i).*dnx\.exe.*/ $csi = /(?i).*csi\.exe.*/ $cdb = /(?i).*cdb\.exe.*/ $bginfo = /(?i).*bginfo\.exe.*/ $appvlp = /(?i).*appvlp\.exe.*/ $xwizard = /(?i).*xwizard\.exe.*/ $wsreset = /(?i).*wsreset\.exe.*/ $wscript = /(?i).*wscript\.exe.*/ $wmic = /(?i).*wmic\.exe.*/ $wab = /(?i).*wab\.exe.*/ $verclsid = /(?i).*verclsid\.exe.*/ $syncappvpublishingserver = /(?i).*syncappvpublishingserver\.exe.*/ $scriptrunner = /(?i).*scriptrunner\.exe.*/ $schtasks = /(?i).*schtasks\.exe.*/ $sc = /(?i).*sc\.exe.*/ $runscripthelper = /(?i).*runscripthelper\.exe.*/ $runonce = /(?i).*runonce\.exe.*/ $rundll32 = /(?i).*rundll32\.exe.*/ $rpcping = /(?i).*rpcping\.exe.*/ $replace = /(?i).*replace\.exe.*/ $regsvr32 = /(?i).*regsvr32\.exe.*/ $regsvcs = /(?i).*regsvcs\.exe.*/ $register_cimprovider = /(?i).*register-cimprovider\.exe.*/ $regedit = /(?i).*regedit\.exe.*/ $regasm = /(?i).*regasm\.exe.*/ condition: any of ($atbroker, $bash, $bitsadmin, $certutil, $cmdkey, $cmstp, $control, $csc, $cscript, $dfsvc, $diskshadow, $dnscmd, $esentutl, $eventvwr, $expand, $extexport, $extrac32, $findstr, $forfiles, $ftp, $gpscript, $hh, $ie4uinit, $ieexec, $infdefaultinstall, $installutil, $makecab, $reg, $print, $presentationhost, $pcwrun, $pcalua, $odbcconf, $msiexec, $mshta, $msdt, $msconfig, $msbuild, $mmc, $microsoft_workflow_compiler, $mavinject, $vsjitdebugger, $tracker, $te, $sqltoolsps, $sqlps, $sqldumper, $rcsi, $msxsl, $msdeploy, $mftrace, $dxcap, $dnx, $csi, $cdb, $bginfo, $appvlp, $xwizard, $wsreset, $wscript, $wmic, $wab, $verclsid, $syncappvpublishingserver, $scriptrunner, $schtasks, $sc, $runscripthelper, $runonce, $rundll32, $rpcping, $replace, $regsvr32, $regsvcs, $register_cimprovider, $regedit, $regasm) } KQL Rule Based on YARA Rule DeviceProcessEvents | where Timestamp >= ago(3d) | where InitiatingProcessFileName matches regex @'(?i).*atbroker\.exe.*|.*bash\.exe.*|.*bitsadmin\.exe.*|.*certutil\.exe.*|.*cmdkey\.exe.*|.*cmstp\.exe.*|.*control\.exe.*|.*csc\.exe.*|.*cscript\.exe.*|.*dfsvc\.exe.*|.*diskshadow\.exe.*|.*dnscmd\.exe.*|.*esentutl\.exe.*|.*eventvwr\.exe.*|.*expand\.exe.*|.*extexport\.exe.*|.*extrac32\.exe.*|.*findstr\.exe.*|.*forfiles\.exe.*|.*ftp\.exe.*|.*gpscript\.exe.*|.*hh\.exe.*|.*ieuinit\.exe.*|.*ieexec\.exe.*|.*infdefaultinstall\.exe.*|.*installutil\.exe.*|.*makecab\.exe.*|.*reg\.exe.*|.*print\.exe.*|.*presentationhost\.exe.*|.*pcwrun\.exe.*|.*pcalua\.exe.*|.*odbcconf\.exe.*|.*msiexec\.exe.*|.*mshta\.exe.*|.*msdt\.exe.*|.*msconfig\.exe.*|.*msbuild\.exe.*|.*mmc\.exe.*|.*microsoft.workflow.compiler\.exe.*|.*mavinject\.exe.*|.*vsjitdebugger\.exe.*|.*tracker\.exe.*|.*te\.exe.*|.*sqltoolsps\.exe.*|.*sqlps\.exe.*|.*sqldumper\.exe.*|.*rcsi\.exe.*|.*msxsl\.exe.*|.*msdeploy\.exe.*|.*mftrace\.exe.*|.*dxcap\.exe.*|.*dnx\.exe.*|.*csi\.exe.*|.*cdb\.exe.*|.*bginfo\.exe.*|.*appvlp\.exe.*|.*xwizard\.exe.*|.*wsreset\.exe.*|.*wscript\.exe.*|.*wmic\.exe.*|.*wab\.exe.*|.*verclsid\.exe.*|.*syncappvpublishingserver\.exe.*|.*scriptrunner\.exe.*|.*schtasks\.exe.*|.*sc\.exe.*|.*runscripthelper\.exe.*|.*runonce\.exe.*|.*rundll32\.exe.*|.*rpcping\.exe.*|.*replace\.exe.*|.*regsvr32\.exe.*|.*regsvcs\.exe.*|.*register-cimprovider\.exe.*|.*regedit\.exe.*|.*regasm\.exe.*' | summarize by InitiatingProcessFileName We now have a method to efficiently convert a detection rule from a legacy SIEM to one that is compatible with Microsoft Sentinel . The next step is understanding how a user can implement this in Sentinel. It is important to consider that the user may need to acquaint themselves with the new SIEM or hire a contractor. Since a contractor wasn’t available, given the circumstances, we decided to ask Security Copilot: Can you create a change control document that shows the steps required to create the detection rule for the KQL query generated above in sentinel. Also include the required level of access to make such a change. Ensure rollback is included. Change Control Document: Creating a Detection Rule in Microsoft Sentinel Change Request Details Change Request ID: [To be assigned] Change Title: Create Detection Rule for Suspicious Process Execution Change Description: Implement a detection rule in Microsoft Sentinel based on the provided KQL query to monitor for suspicious process executions. Steps to Implement the Change Log in to Azure Portal: Navigate to the Azure portal (https://portal.azure.com). Ensure you have the necessary permissions to access Microsoft Sentinel. Access Microsoft Sentinel: In the Azure portal, search for "Microsoft Sentinel" and select the appropriate workspace. Create a New Analytics Rule: Go to the "Analytics" section in the Microsoft Sentinel workspace. Click on "Create" and select "Scheduled query rule." Define Rule Details: Name: Suspicious Process Execution Detection Description: Detects execution of potentially suspicious processes based on the provided KQL query. Severity: High Tactics: Execution Set Rule Logic: Query: Copy and paste the following KQL query: DeviceProcessEvents | where TimeGenerated >= ago(3d) | where InitiatingProcessFileName matches regex @'(?i).*atbroker\.exe.*|.*bash\.exe.*|.*bitsadmin\.exe.*|.*certutil\.exe.*|.*cmdkey\.exe.*|.*cmstp\.exe.*|.*control\.exe.*|.*csc\.exe.*|.*cscript\.exe.*|.*dfsvc\.exe.*|.*diskshadow\.exe.*|.*dnscmd\.exe.*|.*esentutl\.exe.*|.*eventvwr\.exe.*|.*expand\.exe.*|.*extexport\.exe.*|.*extrac32\.exe.*|.*findstr\.exe.*|.*forfiles\.exe.*|.*ftp\.exe.*|.*gpscript\.exe.*|.*hh\.exe.*|.*ie4uinit\.exe.*|.*ieexec\.exe.*|.*infdefaultinstall\.exe.*|.*installutil\.exe.*|.*makecab\.exe.*|.*reg\.exe.*|.*print\.exe.*|.*presentationhost\.exe.*|.*pcwrun\.exe.*|.*pcalua\.exe.*|.*odbcconf\.exe.*|.*msiexec\.exe.*|.*mshta\.exe.*|.*msdt\.exe.*|.*msconfig\.exe.*|.*msbuild\.exe.*|.*mmc\.exe.*|.*microsoft.workflow.compiler\.exe.*|.*mavinject\.exe.*|.*vsjitdebugger\.exe.*|.*tracker\.exe.*|.*te\.exe.*|.*sqltoolsps\.exe.*|.*sqlps\.exe.*|.*sqldumper\.exe.*|.*rcsi\.exe.*|.*msxsl\.exe.*|.*msdeploy\.exe.*|.*mftrace\.exe.*|.*dxcap\.exe.*|.*dnx\.exe.*|.*csi\.exe.*|.*cdb\.exe.*|.*bginfo\.exe.*|.*appvlp\.exe.*|.*xwizard\.exe.*|.*wsreset\.exe.*|.*wscript\.exe.*|.*wmic\.exe.*|.*wab\.exe.*|.*verclsid\.exe.*|.*syncappvpublishingserver\.exe.*|.*scriptrunner\.exe.*|.*schtasks\.exe.*|.*sc\.exe.*|.*runscripthelper\.exe.*|.*runonce\.exe.*|.*rundll32\.exe.*|.*rpcping\.exe.*|.*replace\.exe.*|.*regsvr32\.exe.*|.*regsvcs\.exe.*|.*register-cimprovider\.exe.*|.*regedit\.exe.*|.*regasm\.exe.*' | summarize by InitiatingProcessFileName Query Frequency: 5 minutes Query Period: 3 days Set Alert Details: Alert Rule Name: Suspicious Process Execution Detected Description: Alerts when a suspicious process execution is detected. Severity: High Tactics: Execution Configure Automated Response (Optional): Add any playbooks or automated responses if required. Review and Create: Review the rule configuration. Click "Create" to save and activate the rule. Required Access Level Role: Security Administrator or Sentinel Contributor Permissions: Read and write access to Microsoft Sentinel Ability to create and manage analytics rules Rollback Plan Log in to Azure Portal: Navigate to the Azure portal (https://portal.azure.com). Access Microsoft Sentinel: In the Azure portal, search for "Microsoft Sentinel" and select the appropriate workspace. Delete the Analytics Rule: Go to the "Analytics" section in the Microsoft Sentinel workspace. Locate the "Suspicious Process Execution Detection" rule. Select the rule and click "Delete." Verify Deletion: Ensure the rule is no longer listed in the "Analytics" section. Document the Rollback: Update the change control document to reflect the rollback action. Approval Change Approver: [To be assigned] Approval Date: [To be assigned] Implementation Date Scheduled Date: [To be assigned] Implementation Time: [To be assigned] Rollback Date Scheduled Date: [To be assigned] Rollback Time: [To be assigned] As you can see with the above methods, we have the option now to create a prompt book which can be manually run to efficiently convert AQL and YARA to KQL. But since we had more time to play with, we decide to see if we could do this task in an automated fashion using logic apps. The first step in this process was to create a simplified promptbooks that can be later invoked by a logic app: We exported the AQL queries and imported them directly into Watchlists within Sentinel: Clicking on view logs shows AQLPayLoad stored in the _GetWatchlist('AQL2KQL') table: Since we have this watch list now imported, it simply will not work as the syntax of AQL is not understood by Sentinel: We now need to design a logic app that can help do the conversation directly from the uploaded watchlist, it has to also invoke the relevant prompt book(s) created above: We now have the option of getting Copilot to carry out the conversion via a Logic App so in theory we just have to upload the watch list and let the logic app do the conversation. You can download the following from Microsoft Security Copilot official Github repo, thanks for supporting the automated deployment package. KQL Migrator Azure Logic App Code file : Click here o Make sure to replace the following with your tenant's correct information: <subscription-ID> <ResourceGroup-Name> Sample AQL queries / YARA rules: Click here Conclusion and Consideration So, we've explored how Security Copilot Azure Logic App connector and Promptbooks revolutionizes the integration of AI-driven security solutions into current workflows. This tool not only provides greater customization and smoother system integration but also access to a broader range of ready-made Azure logic security tools integration. We encourage you to experience the efficiency of the Security Copilot Azure Logic App connector in enhancing your security operations. Whilst investigating and understanding AQL/YARA we did not leave the copilot platform, we also found that it can convert to STIX II to as well You can customize the Logic App by automatically creating the Microsoft Sentinel analytics rules via the API If Logic Apps are not suitable, consider adding a step to create control documentation within the promptbook as shown above. Authors Hesham Saad - Sr Cybersecurity Global Blackbelt Hiten Sharma – Sr Cybersecurity Global BlackbeltIdentity forensics with Copilot for Security Identity Analyst Plugin
Microsoft Copilot for Securityis a platform that brings together the power of AI and human expertise to help administrators and security teams respond to attacks faster and more effectively. Copilot for Security is embedded in Microsoft Entra so you can investigate and resolve identity risks, assess identities and access with AI-driven intelligence, and complete complex tasks quickly. Microsoft Copilot in Microsoft Entra gets insights from your Microsoft Entra users, groups, sign-in logs, audit logs, and more. You can explore sign-ins and risky users and get contextualized insights on how to resolve incidents and what to do to protect the accounts in natural language. Built on top of real-time machine learning, Copilot in Microsoft Entra can help you find gaps in access policies, generate identity workflows, and troubleshoot faster. You can also unlock new skills that allow admins at all levels to complete complex tasks such as incident investigation, sign-in log analysis, and more, to gain savings in time and resources.Extending Microsoft Copilot for Security Capabilities with Azure Function Apps
Azure Function Apps offer a convenient way to execute functions in a server-less environment. They allow users to write functions in C#, Java, JavaScript, PowerShell, Python and Typescript which can then be called using several trigger options. One of the most common triggers is the HTTP trigger allowing functions to be called like a REST API. This article shows how to build a Copilot for Security API plugin that calls an Azure Function App.
