← Back to Cybersecurity News Center
Severity
MEDIUM
CVSS
5.0
Priority
0.250
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
CrowdStrike field data shows enterprises have three or more times as many active AI deployments as their own inventories reflect. Untracked AI agents, copilots, and browser extensions operate under inherited user permissions with no security oversight, creating blind spots across endpoints, SaaS platforms, and cloud storage. The core business risk is ungoverned autonomous action: these agents can read, move, or exfiltrate sensitive data with no audit trail and no human in the loop.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
MEDIUM
Medium severity — monitor and assess
TTP Sophistication
HIGH
8 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Enterprise SaaS environments, AI agents, copilots, and browser extensions (vendor-agnostic); CrowdStrike Falcon Platform (Shadow AI Visibility Service, Falcon AIDR)
Are You Exposed?
⚠
You use products/services from Enterprise SaaS environments → Assess exposure
⚠
8 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Business Context
Untracked AI agents operating under employee-level permissions can access, summarize, and transmit confidential business data, including customer records, financial models, and intellectual property, with no audit log and no visibility for security or legal teams. If a regulated data set is processed by a shadow AI tool, the organization may face breach notification obligations it cannot fulfill because it has no record of what data was accessed or where it went. The reputational and contractual exposure from an autonomous agent taking actions on connected systems, such as sending emails, modifying files, or querying databases, without human authorization is compounded by the organization's inability to reconstruct what happened.
You Are Affected If
Your organization uses Microsoft 365 Copilot, Google Workspace Duet, Salesforce Einstein, GitHub Copilot, or any third-party AI copilot or agent, sanctioned or not
Employees can install browser extensions or connect SaaS applications via OAuth without IT approval
Your AI application inventory was built from IT procurement records or user surveys rather than endpoint and network telemetry
AI agents in your environment operate under standard user-level permissions without a separate least-privilege policy applied to agent identities
Your DLP controls do not inspect or block outbound traffic to external LLM API endpoints (e.g., OpenAI, Anthropic, Google Gemini APIs)
Board Talking Points
Our AI tools likely number three times what our records show, and the untracked ones operate with full employee-level access to company data and systems with no audit trail.
We should complete an AI asset inventory using technical discovery tools within the next 30 days and establish an AI governance policy before the next board cycle.
Without action, an autonomous agent could access or exfiltrate sensitive data in a way we cannot detect, reconstruct, or report, creating unquantifiable legal and regulatory exposure.
Technical Analysis
This is a structural governance and visibility gap, not a patchable vulnerability.
CrowdStrike field engagements document systematic undercounting of AI deployments across enterprise SaaS, endpoint, and cloud environments.
Affected weakness patterns: CWE-285 (AI agents operating under excessive inherited user-level permissions with no least-privilege enforcement), CWE-200 (sensitive data submitted to external LLMs at the prompt layer, bypassing DLP controls), and CWE-693 (shadow AI processes bypassing web filtering and policy controls).
Relevant MITRE ATT&CK techniques include T1078 (Valid Accounts, agents inherit user token permissions), T1567 (Exfiltration Over Web Service, data sent to external LLM APIs), T1530 (Data from Cloud Storage, agent access to connected cloud data), T1059 (Command and Scripting Interpreter, agent-executed commands on connected systems), T1526 (Cloud Service Discovery), T1213 (Data from Information Repositories), T1190 (Exploitation of Remote Services), and T1195 (Supply Chain Compromise via MCP-connected and AI-integrated dev tools). CrowdStrike's remediation posture: Falcon AIDR (GA December 2025) for AI-specific detection and response; Shadow AI Visibility Service (launching April 2026) for inventory and footprint mapping; unified data protection for GenAI prompt-layer DLP. No CVE applies. Source quality is vendor-sourced (T3); independent third-party corroboration is not available in this data set.
Action Checklist IR ENRICHED
Triage Priority:
URGENT
Escalate to a formal data breach investigation and engage legal counsel if the OAuth scope and file access log analysis (Step 2 evidence) reveals that any ungoverned AI agent had read or exfiltration-capable access to data stores containing PII, PHI, PCI-DSS-scoped data, or regulated intellectual property, particularly where data volume transferred to LLM API endpoints exceeds a de minimis threshold or where state breach notification laws (e.g., CCPA, NY SHIELD) or sector regulations (HIPAA, GLBA) apply.
1
Step 1: Containment — Run an AI asset discovery sweep across endpoints, SaaS integrations, browser extensions, and cloud-connected services using endpoint telemetry and network egress logs. Do not rely on self-reported counts or procurement records. Add all discovered AI assets to the enterprise asset and software inventories. (Cite: CIS 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory / CIS 2.1 — Establish and Maintain a Software Inventory / D3-ODM — Operational Dependency Mapping)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis: identifying the scope of affected systems and surfacing unknown assets before containment decisions can be made
NIST SI-4 (System Monitoring) — monitor for unauthorized AI processes and anomalous outbound connections to LLM API endpoints
NIST CM-8 (System Component Inventory) — extend inventory to include AI agents, copilots, and browser extensions as trackable system components
CIS 1.1 (Establish and Maintain Detailed Enterprise Asset Inventory) — discover all AI-capable assets including browser extension hosts and SaaS-connected endpoints
CIS 2.1 (Establish and Maintain a Software Inventory) — enumerate all installed AI browser extensions and agent software not currently in the authorized software list
Compensating Control
On Windows endpoints, run: `Get-Process | Where-Object {$_.MainWindowTitle -eq ''} | Select-Object Name, Id, Path` combined with `netstat -ano` filtered against known LLM API IP ranges for api.openai.com, api.anthropic.com, and generativelanguage.googleapis.com. Use osquery with query `SELECT name, identifier, path FROM browser_extensions WHERE name LIKE '%AI%' OR name LIKE '%GPT%' OR name LIKE '%Copilot%' OR name LIKE '%assistant%'` across enrolled endpoints. For SaaS OAuth exposure, export OAuth grant lists via Google Workspace Admin SDK or Microsoft Entra ID `Get-MgOAuth2PermissionGrant` PowerShell command and grep for AI vendor app IDs.
Preserve Evidence
Before initiating discovery, preserve: (1) a snapshot of current browser extension inventory from endpoint management (Intune, JAMF, or osquery browser_extensions table) to establish a pre-remediation baseline; (2) current OAuth grant exports from all SaaS platforms (M365, Google Workspace, Salesforce) showing granted scopes, grant dates, and authorized user counts; (3) 30-day DNS query logs filtered for *.openai.com, *.anthropic.com, *.googleapis.com/generativelanguage, *.azure.com/openai, *.cohere.ai to identify AI endpoints already in use; (4) network proxy or firewall egress logs showing data volume transferred to LLM API endpoints per user or device.
2
Step 2: Detection — Query endpoint logs for processes or browser extensions making outbound connections to known LLM API endpoints. Flag any agent operating under a standard user token that is accessing cloud storage (T1530) or submitting data to external web services (T1567). Review SaaS OAuth grant lists for AI applications with broad permission scopes. Enable audit logging across all endpoints and SaaS platforms where not already active. (Cite: NIST AU-2 — Event Logging / NIST AU-6 — Audit Record Review, Analysis, and Reporting / CIS 8.2 — Collect Audit Logs / D3-LAM — Local Account Monitoring / D3-EBWSAM — Endpoint-based Web Server Access Mediation)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis: correlating endpoint telemetry with network egress data to identify adversarial or ungoverned autonomous behavior patterns
NIST AU-6 (Audit Record Review, Analysis, and Reporting) — review endpoint and proxy logs for AI agent outbound connections to LLM APIs on a defined frequency
NIST AU-2 (Event Logging) — ensure logging is configured to capture browser extension network activity and process-level outbound connection events
NIST SI-4 (System Monitoring) — detect unauthorized data submission to external LLM APIs (T1567) and access to cloud storage under inherited user tokens (T1530)
CIS 8.2 (Collect Audit Logs) — verify audit logging is enabled and collecting browser process network events, SaaS authentication logs, and OAuth grant activity
Compensating Control
Deploy Sysmon with a configuration that includes NetworkConnect events (Event ID 3) filtered on destination hostnames matching openai.com, anthropic.com, googleapis.com, azure.com. Query with: `Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' | Where-Object {$_.Id -eq 3 -and $_.Message -match 'openai|anthropic|googleapis'}`. For OAuth scope analysis without a SIEM, use a Python script against the Microsoft Graph API or Google Workspace Admin SDK to flag any AI application granted Files.ReadWrite.All, Mail.Read, or equivalent broad-scope permissions. Apply the public Sigma rule 'proc_creation_win_lolbin_data_exfiltration' as a starting template adapted to flag curl/Invoke-WebRequest calls to LLM API endpoints.
Preserve Evidence
Preserve before flagging or alerting: (1) Sysmon Event ID 3 (NetworkConnect) records showing process name, user SID, destination IP and hostname for all LLM API destinations — this establishes which user accounts are running which AI agents; (2) Windows Security Event Log Event ID 4663 (Object Access) for any files accessed immediately before outbound LLM API connections, confirming T1530 data staging behavior; (3) SaaS audit logs (M365 Unified Audit Log, Google Workspace Admin Audit) for OAuth token issuance events to AI application client IDs within the last 90 days; (4) browser extension manifest files (located at `%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\[ext_id]\manifest.json`) for extensions with declared permissions including 'storage', 'tabs', 'clipboardRead', or '<all_urls>' that indicate broad data access capability.
3
Step 3: Eradication — Revoke OAuth grants for unvetted AI applications via the established access revoking process. Apply least-privilege to any AI agent or copilot that inherited broad user-level permissions. Block egress to unapproved LLM API endpoints at the proxy or firewall layer. Remove unsanctioned AI browser extensions via endpoint management policy and update the authorized software inventory. (Cite: NIST AC-6 — Least Privilege / NIST AC-4 — Information Flow Enforcement / NIST AC-20 — Use of External Systems / CIS 2.3 — Address Unauthorized Software / CIS 6.2 — Establish an Access Revoking Process / D3-UAP — User Account Permissions / D3-PBWSAM — Proxy-based Web Server Access Mediation)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication: removing unauthorized components from the environment and eliminating the conditions that allowed ungoverned AI agents to persist and operate
NIST IR-4 (Incident Handling) — execute eradication as a formal phase of the incident handling capability, documenting each revoked grant and blocked endpoint
NIST AC-6 (Least Privilege) — reduce AI agent and copilot permissions to the minimum required for sanctioned functions, replacing inherited broad user-level tokens
NIST AC-2 (Account Management) — revoke OAuth grants for unvetted AI applications as unauthorized account-equivalent access relationships
NIST CM-7 (Least Functionality) — block egress to unapproved LLM API endpoints to eliminate unauthorized external service connections
CIS 5.4 (Restrict Administrator Privileges to Dedicated Administrator Accounts) — prevent AI agents from operating under elevated or overly-permissive user tokens
CIS 2.3 (Address Unauthorized Software) — remove unsanctioned AI browser extensions via endpoint management policy enforcement
Compensating Control
Revoke OAuth grants via PowerShell: `Remove-MgOAuth2PermissionGrant -OAuth2PermissionGrantId <id>` for M365 or equivalent Google Workspace Admin SDK call. Block LLM API egress on Windows hosts without a proxy by adding entries to the Windows Hosts file (`C:\Windows\System32\drivers\etc\hosts`) pointing api.openai.com, api.anthropic.com, and generativelanguage.googleapis.com to 127.0.0.1 as an immediate tactical block, then follow with a permanent firewall rule via `netsh advfirewall firewall add rule name='Block LLM APIs' dir=out action=block remoteip=<resolved_IP_ranges>`. Remove Chrome extensions without MDM using a Group Policy Object setting `ExtensionInstallBlocklist` with the specific extension IDs identified in Step 2.
Preserve Evidence
Before revoking any grant or blocking any endpoint, preserve: (1) full export of all OAuth grants with scopes, grant timestamps, and last-used timestamps from M365 Entra ID (`Get-MgOAuth2PermissionGrant -All`) and Google Workspace — this is your pre-eradication state record required for post-incident review; (2) screenshots or JSON exports of browser extension permission manifests for all extensions being removed, preserving the declared permission scopes as evidence of the exposure; (3) firewall and proxy logs covering the 90 days prior to blocking, capturing total data volume transferred to each LLM API endpoint per user — this establishes whether data exfiltration volume warrants escalation to a data breach investigation; (4) user account to AI agent mapping showing which service accounts or user tokens each ungoverned agent inherited permissions from.
4
Step 4: Recovery — Validate that the AI application inventory reflects actual deployment counts via telemetry, not self-reporting. Confirm DLP controls cover prompt-layer traffic to external LLM APIs. Verify that egress blocks to unapproved LLM endpoints are enforced at the proxy layer. Schedule recurring OAuth grant and browser extension inventory reviews on at minimum a weekly cadence during the remediation phase. (Cite: NIST AC-4 — Information Flow Enforcement / NIST AU-6 — Audit Record Review, Analysis, and Reporting / CIS 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory / CIS 1.2 — Address Unauthorized Assets / CIS 2.1 — Establish and Maintain a Software Inventory)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery: verifying that the environment has returned to a known-good state and confirming that controls are in place to prevent recurrence of ungoverned AI deployment
NIST IR-4 (Incident Handling) — verify recovery completeness by confirming telemetry-driven inventory aligns with post-eradication expected state
NIST SI-7 (Software, Firmware, and Information Integrity) — use integrity verification to confirm no unsanctioned AI extensions or agents have been reinstalled post-eradication
NIST AU-6 (Audit Record Review, Analysis, and Reporting) — establish recurring review of OAuth grant lists and browser extension inventories at weekly frequency during remediation phase
NIST SI-4 (System Monitoring) — confirm DLP monitoring covers HTTPS traffic to LLM API endpoints including prompt-layer data submission
CIS 7.1 (Establish and Maintain a Vulnerability Management Process) — integrate recurring AI asset discovery into the vulnerability management cadence
CIS 8.2 (Collect Audit Logs) — validate that logging gaps identified during the discovery phase have been closed and that AI-related egress events are now captured
Compensating Control
Run a post-remediation osquery scan using `SELECT name, identifier, path, permissions FROM browser_extensions` and diff the output against the pre-remediation baseline captured in Step 1 to confirm removal and detect any reinstallation. For DLP coverage validation without a commercial DLP tool, configure a Squid proxy with SSL bump enabled and write an ACL that logs and blocks POST requests to /v1/chat/completions, /v1/messages, and equivalent LLM inference endpoints — inspect request bodies for PII patterns using a regex-based ICAP server such as c-icap with ClamAV. Schedule a weekly cron job or scheduled task to re-run the OAuth grant export and diff against the post-eradication state, alerting on any new AI application grants.
Preserve Evidence
During recovery validation, collect: (1) a fresh osquery browser extension inventory and OAuth grant export taken immediately after eradication, timestamped, to serve as the new clean-state baseline; (2) proxy or DNS logs from the 7 days post-eradication confirming zero successful connections to blocked LLM API endpoints — any hits indicate an eradication gap or policy bypass; (3) DLP policy coverage confirmation showing that outbound HTTPS POST traffic to LLM API hostnames is inspected, not tunneled blind through TLS — capture a sample DLP log entry showing prompt-layer traffic classification as evidence the control is functioning; (4) a dated reconciliation report comparing telemetry-derived AI asset count against prior self-reported count, documenting the specific gap as a measurable recovery milestone.
5
Step 5: Post-Incident — Establish a formal AI governance policy within 30 days covering sanctioned tools, permitted data classifications for AI processing, and agent permission standards. Map AI asset discovery outputs to your existing CMDB or asset management process. Integrate AI-specific controls into your next GRC compliance assessment cycle, including access control policy coverage for AI agents. (Cite: NIST AC-1 — Policy and Procedures / NIST AC-2 — Account Management / NIST AC-20 — Use of External Systems / CIS 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory / CIS 3.2 — Establish and Maintain a Data Inventory / CIS 6.1 — Establish an Access Granting Process)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: conducting lessons-learned, updating policies, and improving detection and governance capabilities based on findings from this incident
NIST IR-4 (Incident Handling) — update the incident handling capability to include AI governance gaps as a recognized incident class with defined response procedures
NIST IR-8 (Incident Response Plan) — revise the IR plan to incorporate AI asset discovery as a standing preparation activity and add AI-specific escalation criteria
NIST RA-3 (Risk Assessment) — add ungoverned AI deployments as an explicit risk category in the next risk assessment cycle, including agent permission scope and data classification exposure
NIST CM-8 (System Component Inventory) — integrate AI agents, copilots, and browser extensions into the CMDB as managed asset classes with defined approval workflows
NIST AC-2 (Account Management) — define AI agent permission standards as part of account provisioning policy, requiring explicit least-privilege scoping for all AI service accounts
CIS 1.1 (Establish and Maintain Detailed Enterprise Asset Inventory) — extend CMDB scope to include AI tools as a tracked asset class with discovery cadence defined
CIS 7.2 (Establish and Maintain a Remediation Process) — add AI governance control gaps to the risk-based remediation strategy with defined SLAs for sanctioning or removing AI deployments
Compensating Control
For teams without a GRC platform, create a lightweight AI governance register as a version-controlled CSV or Git repository documenting: tool name, vendor, OAuth scopes granted, data classifications permitted, approval status, and assigned owner. Automate weekly diff reporting by scheduling the osquery extension query and OAuth grant export as cron jobs with output compared against the register, emailing a delta report to the security team. Use the NIST AI RMF (AI 100-1) Govern function as a free reference framework to structure the policy — it is directly complementary to NIST CSF 2.0 and requires no licensing.
Preserve Evidence
Preserve as post-incident documentation: (1) the full timeline of AI asset discovery findings — specifically the ratio of telemetry-discovered AI deployments versus prior self-reported count — as quantitative evidence of the governance gap for executive and board reporting; (2) the pre- and post-remediation OAuth grant exports and browser extension inventories as before/after evidence packages supporting the lessons-learned report; (3) a documented mapping of which ungoverned AI agents had access to which data classifications (PII, PHI, financial, IP) based on the OAuth scopes and file access logs collected in Steps 1 and 2 — this is required to determine whether a data breach notification assessment is needed; (4) the DLP coverage gap analysis from Step 4, retained as evidence supporting the business case for AI-specific policy and tooling investment.
Recovery Guidance
Post-containment, maintain weekly telemetry-driven reconciliation of the AI asset inventory against the CMDB for a minimum of 90 days, as CrowdStrike field data indicates shadow AI re-emergence is rapid without enforced allow-listing at the proxy and endpoint management layer. Confirm that DLP inspection of LLM API prompt-layer traffic is functioning and classifying outputs — not just blocking domains — because users will pivot to sanctioned tools and attempt to submit the same sensitive data through approved channels. Retain all OAuth grant exports, DNS egress logs, and browser extension inventories from the remediation period for a minimum of one year to support any regulatory inquiry or downstream breach notification assessment triggered by the data classification review.
Key Forensic Artifacts
OAuth grant audit logs from M365 Entra ID and Google Workspace: export all grants with client_id, scope, consentType, and last-used timestamp — these identify which AI applications held persistent delegated access to corporate data under user identities with no security team visibility
DNS query logs and proxy egress logs filtered to LLM API hostnames (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, *.azure.com/openai): preserve per-user and per-device query frequency and data transfer volume to establish the scope of prompt-layer data submission and support T1567 (Exfiltration Over Web Service) triage
Browser extension manifest.json files from `%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\[ext_id]\` on Windows and `~/Library/Application Support/Google/Chrome/Default/Extensions/[ext_id]/` on macOS: preserve declared permissions (especially 'storage', 'tabs', 'clipboardRead', '<all_urls>') as evidence of the data access surface each unsanctioned AI extension had at the time of discovery
Sysmon Event ID 3 (NetworkConnect) logs correlating process name, user SID, and destination hostname for LLM API endpoints: these link specific ungoverned AI agent processes to specific user accounts, establishing the permission inheritance chain that enabled T1530 (Data from Cloud Storage) access
SaaS platform audit logs (M365 Unified Audit Log 'FileAccessed' and 'FileDownloaded' operations, Google Workspace Drive Audit 'download' events) correlated with the timestamps of outbound LLM API connections: this correlation is the primary evidence set for determining whether ungoverned agents staged and submitted sensitive documents to external LLM endpoints, and is required input for any breach notification threshold analysis
Detection Guidance
Primary detection surfaces are network egress logs, endpoint process telemetry, and SaaS OAuth grant reports.
Per NIST AU-2 (Event Logging), define and enable logging for outbound connection events, OAuth authorization grants, cloud storage access, and data transfer events across all enterprise systems.
Per NIST AU-6 (Audit Record Review, Analysis, and Reporting), configure SIEM correlation to join user identity tokens (T1078 ) with cloud storage access events (T1530 ) and external web service data transfers (T1567 ) to identify AI agents acting autonomously under inherited permissions.
Per NIST AU-3 (Content of Audit Records), ensure log records capture the initiating process, user context, destination, timestamp, and data volume to support triage. Query proxy or firewall logs for outbound HTTPS connections to known LLM API endpoints (e.g., api.openai.com, api.anthropic.com, generativelanguage.googleapis.com) originating from non-IT-managed processes or user-context agents — this is the primary behavioral indicator for T1567 and T1590 . Apply D3-PBWSAM (Proxy-based Web Server Access Mediation) to intercept and log all outbound AI API traffic; apply D3-EBWSAM (Endpoint-based Web Server Access Mediation) to enforce endpoint-level controls on browser extension web access. Apply D3-LAM (Local Account Monitoring) to detect AI agents authenticating or acting under local user accounts with elevated or broad scope. For SaaS environments, pull OAuth application grant reports from Google Workspace, Microsoft 365, and Salesforce; flag any AI application with scopes covering email, files, or calendar read/write that was not approved through IT procurement — this maps directly to NIST AC-20 (Use of External Systems) and NIST AC-3 (Access Enforcement). Per CIS 8.2 (Collect Audit Logs), confirm audit logging is enabled across all endpoints, SaaS platforms, and cloud storage services before initiating correlation queries — ungoverned AI processes create no audit trail by default, and log coverage gaps are themselves an indicator of risk. If CrowdStrike Falcon AIDR or the Shadow AI Visibility Service (April 2026 launch) is deployed, use AI-specific behavioral detections as a supplemental signal layer; telemetry-based discovery should remain the primary control, not vendor-specific tooling alone.
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
MITRE ATT&CK Hunting Queries (3)
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Sentinel rule: Web application exploit patterns
KQL Query Preview
Read-only — detection query only
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("PaloAlto", "Fortinet", "F5", "Citrix")
| where Activity has_any ("attack", "exploit", "injection", "traversal", "overflow")
or RequestURL has_any ("../", "..\\\\", "<script", "UNION SELECT", "\${jndi:")
| project TimeGenerated, DeviceVendor, SourceIP, DestinationIP, RequestURL, Activity, LogSeverity
| sort by TimeGenerated desc
Sentinel rule: Suspicious PowerShell command line
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| where ProcessCommandLine has_any ("-enc", "-nop", "bypass", "hidden", "downloadstring", "invoke-expression", "iex", "frombase64", "new-object net.webclient")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| sort by Timestamp desc
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1078
T1190
T1567
T1526
T1059
T1213
+2
AC-2
AC-6
IA-2
IA-5
CA-8
RA-5
+11
164.312(a)(1)
164.308(a)(6)(ii)
MITRE ATT&CK Mapping
T1078
Valid Accounts
defense-evasion
T1190
Exploit Public-Facing Application
initial-access
T1567
Exfiltration Over Web Service
exfiltration
T1526
Cloud Service Discovery
discovery
T1059
Command and Scripting Interpreter
execution
T1213
Data from Information Repositories
collection
T1195
Supply Chain Compromise
initial-access
T1530
Data from Cloud Storage
collection
Guidance Disclaimer
