← Back to Cybersecurity News Center
Severity
HIGH
CVSS
5.0
Priority
0.659
×
Tip
Pick your view
Analyst for full detail, Executive for the short version, or Plain & Simple if you are not a tech person.
Analyst
Executive
Plain & Simple
Executive Summary
Instructure, the company behind Canvas LMS, disclosed a cybersecurity incident on May 1, 2026, placing Canvas Data 2 and Canvas Beta into maintenance mode amid an active investigation. The affected platform is used by millions of students and educators globally; potential exposure of personally identifiable information has not been confirmed or ruled out. This is the second incident in eight months, indicating sustained targeting of Instructure's infrastructure and elevating concerns about data stewardship across the education technology sector.
Plain & Simple
Here’s what you need to know.
No jargon. Just the basics.
👤
Are you affected?
Probably, if you are a student or teacher who uses Canvas, your personal information may have been exposed.
🔓
What got out
Suspected: student and educator personal information, not yet confirmed by Instructure
Suspected: account data from Canvas LMS, Canvas Data 2, and Canvas Beta
Confirmed: Canvas services were disrupted as of May 1, 2026
✅
Do this now
1 Change your Canvas account password to something new and unique. 2 Turn on a second password sent to your phone for your Canvas login if your school allows it. 3 Watch your school email for an official message from your institution or Instructure about next steps.
👀
Watch for these
Emails or messages pretending to be from Canvas or your school asking for your password.
Unexpected login alerts from your Canvas account.
Scam messages using your name or school details to seem more believable.
🌱
Should you worry?
The company has not confirmed what data, if any, was taken. You do not need to panic right now, but changing your Canvas password is a simple, low-effort step worth taking today.
Want more detail? Switch to the full analyst view →
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
HIGH
High severity — prioritize for investigation
Actor Attribution
HIGH
ShinyHunters
TTP Sophistication
HIGH
8 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Instructure Canvas LMS, Canvas Data 2, Canvas Beta
Are You Exposed?
⚠
Your industry is targeted by ShinyHunters → Heightened risk
⚠
You use products/services from Instructure Canvas LMS → 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
Canvas LMS serves as the academic backbone for many universities, K-12 systems, and corporate training programs; a confirmed data breach could expose student records, grades, and personal information subject to FERPA and equivalent international education privacy laws. Operational disruption to Canvas Data 2 and Canvas Beta affects institutions relying on these services for reporting, analytics, and development testing, creating downstream delays in academic and administrative workflows. A second incident within eight months compounds reputational and contractual risk, potentially triggering breach notification obligations and vendor review clauses in institutional contracts.
You Are Affected If
Your institution or organization runs Canvas LMS, Canvas Data 2, or Canvas Beta in production or testing environments
Your Canvas deployment stores or processes student PII, staff records, or institutional data
Your environment uses Canvas API integrations or third-party apps authorized via OAuth to Canvas
Your Canvas Data 2 pipelines connect to external data warehouses or analytics platforms
You have not reviewed Canvas admin account access, API keys, or OAuth token grants within the past 90 days
Board Talking Points
Canvas LMS, used by our institution, disclosed a cybersecurity incident on May 1, 2026, with potential student and educator data exposure under investigation.
IT and security teams should immediately audit Canvas access credentials and monitor Instructure's official updates for remediation guidance within the next 24-48 hours.
Without active monitoring and rapid response to Instructure's forthcoming guidance, we risk delayed breach notification obligations and reputational harm if student data is confirmed exposed.
FERPA (Family Educational Rights and Privacy Act) — Canvas LMS holds student education records. If PII exposure is confirmed, institutions must assess whether a FERPA disclosure obligation is triggered. FERPA does not have a mandatory breach notification timeline but requires institutions to control unauthorized disclosure of education records. Verify with your institution's legal or compliance office.
COPPA (Children's Online Privacy Protection Act) — If the affected Canvas environment serves students under age 13, COPPA obligations may apply to any confirmed exposure of personal information. Assess whether your institution's Canvas deployment is in scope.
State data breach notification laws — Most U.S. states require notification when PII of residents is exposed. Scope and timelines vary by state. If student or staff PII exposure is confirmed, initiate your breach notification assessment process immediately and engage legal counsel to determine applicable state obligations.
GDPR / applicable international privacy law — Institutions with students or staff in the EU or other jurisdictions with mandatory breach notification requirements should assess whether a 72-hour supervisory authority notification obligation is triggered upon confirmation of personal data exposure.
Technical Analysis
Instructure disclosed an active cybersecurity incident affecting Canvas LMS, Canvas Data 2, and Canvas Beta as of May 1, 2026.
Root cause has not been confirmed; no CVE has been assigned.
Suspected vulnerability classes based on incident characteristics are CWE-306 (Missing Authentication for Critical Function), CWE-287 (Improper Authentication), and CWE-359 (Exposure of Private Personal Information to an Unauthorized Actor).
MITRE ATT&CK techniques associated with this incident pattern include T1566 (Phishing), T1199 (Trusted Relationship), T1530 (Data from Cloud Storage), T1657 (Financial Theft), T1213 (Data from Information Repositories), T1190 (Exploit Public-Facing Application), T1486 (Data Encrypted for Impact), and T1078 (Valid Accounts). ShinyHunters has been surfaced as a suspected threat actor; no official attribution has been established. Canvas Data 2 and Canvas Beta entered maintenance mode concurrent with disclosure, suggesting operational disruption beyond initial scope. External forensic investigators are engaged. No patch, vendor advisory with remediation steps, or confirmed attack vector has been published as of disclosure. CVSS base score and vendor scoring are pending official NVD and vendor publication. Source quality score is 0.56, reflecting early-stage reporting.
Action Checklist IR ENRICHED
Triage Priority:
URGENT
Escalate immediately to institutional legal counsel, privacy officer, and CISO if Instructure confirms PII exfiltration from Canvas Data 2 or Canvas LMS user records, as FERPA notification obligations and applicable state breach notification statutes (which vary by jurisdiction but commonly require notification within 30–72 hours) would be triggered; also escalate if internal log review identifies Canvas admin account compromise or unauthorized bulk data exports from your institution's Canvas environment independent of Instructure's investigation.
1
Step 1: Containment — Audit all active Canvas LMS, Canvas Data 2, and Canvas Beta integrations in your environment. Temporarily restrict API access and third-party integrations to Canvas until Instructure confirms the attack vector and scope. Review Canvas OAuth tokens and API keys issued in the last 90 days; revoke any that cannot be attributed to a known authorized application or user. Apply least-privilege access controls to all Canvas API service accounts immediately. (Cite: NIST AC-6 — Least Privilege / NIST AC-20 — Use Of External Systems / NIST AC-2 — Account Management / CIS 6.2 — Establish an Access Revoking Process / D3-CRO — Credential Rotation / D3-UAP — User Account Permissions)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST AC-2 (Account Management)
NIST AC-17 (Remote Access)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
CIS 6.2 (Establish an Access Revoking Process)
Compensating Control
Export the full OAuth token and API key inventory from your Canvas institution admin console under Account > Developer Keys; pipe the JSON output to a spreadsheet and cross-reference each client_id against your authorized app registry. For tokens with no matching owner, use the Canvas API endpoint GET /api/v1/audit/authentication/logins?per_page=100 with your admin token to pull the last 90 days of authentication events associated with that client_id. Revoke unattributed tokens immediately via DELETE /api/v1/developer_keys/:id. This is achievable by one analyst with curl or Postman in under two hours.
Preserve Evidence
Before revoking tokens, capture the full Canvas Developer Keys list (admin console export or API dump) and the Canvas Authentication Audit Log for the 90-day window preceding May 1, 2026. Preserve timestamps, client_id values, and associated user or service account identifiers. This establishes which OAuth clients were active during the incident window and provides the baseline for determining whether any third-party LTI integration or Canvas Data 2 pipeline connector was used as an entry or exfiltration vector.
2
Step 2: Detection — Review identity and access logs for Canvas for anomalous authentication events, including logins from unexpected geographic locations, off-hours access, or service account activity outside normal patterns. Pull Canvas audit logs from the institution admin console for the period surrounding May 1, 2026. Monitor for bulk data export events from Canvas Data 2. No confirmed IOC patterns are available from official sources as of this item's disclosure date. Ensure audit logging is active and log collection is confirmed across all Canvas-connected systems. (Cite: NIST AU-2 — Event Logging / NIST AU-3 — Content Of Audit Records / NIST AU-6 — Audit Record Review, Analysis, And Reporting / CIS 8.2 — Collect Audit Logs / D3-LAM — Local Account Monitoring)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST IR-5 (Incident Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-12 (Audit Record Generation)
NIST SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
Compensating Control
Pull Canvas audit logs via the Canvas API: GET /api/v1/audit/authentication/logins and GET /api/v1/audit/grade_change/courses/:course_id for the April 15 – May 10, 2026 window. Pipe output to jq and filter for login events where pseudonym_id differs from historical baseline or where created_at timestamps fall between 00:00–05:00 institution local time. For Canvas Data 2 bulk export monitoring, query your institution's Canvas Data 2 job history table (cd2_requests or equivalent in your data warehouse) for export jobs initiated by service accounts outside scheduled pipeline windows. If your institution uses Splunk Free or Elastic Free tier, load the JSON audit exports and alert on event_type='login' with country_code != your expected country.
Preserve Evidence
Capture Canvas Authentication Audit Log entries (event_type, pseudonym_id, user_id, created_at, ip_address, country_code) for April 1 – May 10, 2026. Separately capture Canvas Data 2 job execution logs showing which accounts triggered data exports, export scope (table names, row counts), and destination endpoints. Given this is the second incident in eight months, also pull the equivalent log window from the prior incident period for pattern comparison. Preserve raw JSON before any log rotation occurs — Canvas audit log retention is institution-configurable and may be short.
3
Step 3: Eradication — No confirmed patch or remediation guidance has been published by Instructure. Monitor Instructure's official security blog for remediation steps. If CWE-287 or CWE-306 are confirmed, enforce MFA on all Canvas admin and API accounts immediately and harden authentication configuration. Rotate all Canvas admin credentials, API keys, and OAuth tokens regardless of suspected compromise status. Verify that no unauthorized accounts were provisioned during the incident window. (Cite: NIST AC-7 — Unsuccessful Logon Attempts / NIST AC-2 — Account Management / CIS 6.3 — Require MFA for Externally-Exposed Applications / CIS 6.5 — Require MFA for Administrative Access / CIS 5.2 — Use Unique Passwords / D3-MFA — Multi-factor Authentication / D3-CH — Credential Hardening / D3-CRO — Credential Rotation)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST SI-2 (Flaw Remediation)
NIST IA-5 (Authenticator Management)
NIST IA-8 (Identification and Authentication — Non-Organizational Users)
CIS 6.3 (Require MFA for Externally-Exposed Applications)
CIS 6.5 (Require MFA for Administrative Access)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
Without waiting for Instructure's root cause, harden now against CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function) proactively: (1) In Canvas admin console, navigate to Account > Authentication and enforce MFA for all admin roles and any account with API token generation privileges. (2) Rotate all Canvas admin account passwords and force re-enrollment of MFA factors. (3) Disable the Canvas Beta environment at the institution level if your institution does not actively use it for testing, as it was specifically placed in maintenance mode and represents an unconfirmed attack surface. (4) Set a calendar reminder to check https://www.instructure.com/resources/blog for updates every 24 hours until official remediation guidance is published — note this URL has not been independently verified as of this response and should be confirmed against the official Instructure site.
Preserve Evidence
Before hardening authentication configuration, export the current Canvas authentication provider settings (SAML, LDAP, or native Canvas auth configuration) from Account > Authentication as a baseline. Document which admin accounts currently lack MFA enrollment by running GET /api/v1/accounts/:account_id/admins and cross-referencing against your IdP MFA enrollment report. This documents the pre-remediation authentication posture and supports a post-remediation comparison to confirm hardening was effective.
4
Step 4: Recovery — Once Instructure publishes root cause and remediation guidance, validate that all Canvas API credentials, OAuth tokens, and admin accounts have been rotated and documented. Confirm Canvas Data 2 pipeline integrity before resuming automated data exports. Re-enable suspended integrations only after verifying they were not part of the attack path. Confirm MFA enforcement is active on all re-enabled accounts. Retain all audit logs collected during the incident period per your defined retention policy. (Cite: NIST AC-2 — Account Management / NIST AU-11 — Audit Record Retention / NIST AU-9 — Protection Of Audit Information / CIS 6.1 — Establish an Access Granting Process / CIS 6.2 — Establish an Access Revoking Process / D3-CRO — Credential Rotation / D3-UAP — User Account Permissions)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST IR-4 (Incident Handling)
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST CP-10 (System Recovery and Reconstitution)
NIST AU-9 (Protection of Audit Information)
CIS 7.2 (Establish and Maintain a Remediation Process)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
Compensating Control
Before re-enabling Canvas Data 2 pipelines, run a row-count and schema-hash comparison between your last known-good data warehouse snapshot (pre-April 2026) and the current state. Use a SQL query against your data warehouse: SELECT table_name, COUNT(*) FROM canvas_data_2_tables GROUP BY table_name and compare against a saved baseline. For OAuth token rotation verification, re-run the GET /api/v1/developer_keys inventory and confirm no client_id values match the pre-rotation list. For each LTI integration being re-enabled, verify the tool's redirect_uri and launch URL against the vendor's current published documentation before restoring.
Preserve Evidence
Before resuming Canvas Data 2 exports, capture a hash of your current data warehouse tables for the most sensitive datasets (user PII tables, enrollment records, grade tables) using md5sum or sha256sum on exported CSVs, and compare against pre-incident baselines. This detects whether any unauthorized data modification occurred during the incident window — relevant because the attack vector and whether data was modified (not just exfiltrated) remains unconfirmed as of this disclosure.
5
Step 5: Post-Incident — Evaluate your institution's dependency on Canvas Data 2 for data pipeline continuity planning using operational dependency mapping. Review all third-party app integrations authorized in your Canvas environment against a least-privilege baseline and revoke any that cannot be justified. Confirm your data inventory includes Canvas-held PII so breach notification scope can be assessed quickly if exposure is confirmed. Update your access granting and revoking processes to include periodic Canvas integration reviews. Document findings for the next security review cycle. (Cite: NIST AC-6 — Least Privilege / NIST AC-20 — Use Of External Systems / CIS 3.2 — Establish and Maintain a Data Inventory / CIS 6.1 — Establish an Access Granting Process / CIS 6.2 — Establish an Access Revoking Process / D3-ODM — Operational Dependency Mapping / D3-UAP — User Account Permissions)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST RA-3 (Risk Assessment)
NIST SI-12 (Information Management and Retention)
NIST AU-11 (Audit Record Retention)
CIS 3.2 (Establish and Maintain a Data Inventory)
CIS 3.3 (Configure Data Access Control Lists)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
Conduct a scoped LTI and API integration audit using the Canvas API: GET /api/v1/accounts/:account_id/lti_apps and GET /api/v1/developer_keys?per_page=100, then map each integration's data scope (what Canvas data fields it can access) against documented business need. Flag any integration with access to PII fields (email, SIS ID, enrollment data) that lacks a current data processing agreement. For breach notification scoping, query your Canvas SIS integration to enumerate the total count of active user records with email addresses — this establishes the notification population if PII exposure is confirmed. This is achievable with Canvas API access and a spreadsheet in one analyst-day.
Preserve Evidence
Retain all Canvas audit log exports, API key inventory snapshots, authentication event logs, and Canvas Data 2 job history logs from the investigation window for a minimum of 12 months per NIST AU-11 (Audit Record Retention). Given this is the second incident in eight months, these records will be critical for identifying whether the same initial access vector was reused. If PII exposure is confirmed, these logs will also constitute required evidence for breach notification documentation under applicable regulations (FERPA, state data breach statutes).
Recovery Guidance
Do not resume Canvas Data 2 automated pipeline exports until Instructure has published a confirmed root cause and your institution has independently verified that no unauthorized OAuth clients or API keys remain active in your developer key inventory. Given this is Instructure's second incident in eight months, maintain elevated monitoring of Canvas authentication audit logs and Canvas Data 2 job history for a minimum of 60 days post-Instructure remediation confirmation, watching specifically for service account authentications from unexpected IP ranges or off-schedule bulk export jobs. Treat the prior incident's timeframe as a secondary investigation window — review whether any anomalous access patterns present in the current incident also appeared during the prior incident, as this would indicate a persistent access mechanism that survived the first remediation.
Key Forensic Artifacts
Canvas Authentication Audit Log (GET /api/v1/audit/authentication/logins): captures OAuth client_id, user_id, pseudonym_id, IP address, country_code, and created_at timestamp — the primary source for identifying unauthorized API client activity or anomalous admin logins surrounding May 1, 2026
Canvas Developer Keys export (admin console or GET /api/v1/developer_keys): documents all OAuth 2.0 client credentials and API tokens issued to third-party integrations; abnormal entries or tokens with no attributable owner are a direct indicator of unauthorized API access in a Canvas-specific breach
Canvas Data 2 job execution history (available in your institution's data warehouse or Canvas Data 2 admin interface): records which accounts triggered data export jobs, the tables exported, row counts, and destination endpoints — critical for scoping potential PII exfiltration from the Canvas Data 2 pipeline specifically called out in this incident
Canvas LTI integration redirect URIs and launch URL configurations (GET /api/v1/accounts/:account_id/lti_apps): a compromised LTI tool registration is a plausible lateral vector in a Canvas breach; mismatched or newly-added redirect_uri values against known vendor documentation indicate potential OAuth redirect hijacking consistent with CWE-287
Institution IdP (SSO) authentication logs for Canvas service provider entity: if your institution uses SAML or OIDC for Canvas authentication, the IdP-side logs (Shibboleth, Azure AD, Okta) will contain authentication assertions that Canvas-side audit logs may not fully capture — cross-correlating IdP assertion timestamps with Canvas audit login events can identify forged or replayed authentication tokens consistent with CWE-306 (Missing Authentication for Critical Function)
Detection Guidance
No confirmed IOCs are available as of the May 1, 2026 disclosure.
Detection priorities are based on suspected CWEs (CWE-306, CWE-287, CWE-359) and associated MITRE ATT&CK techniques (T1566 , T1199 , T1530 , T1657 , T1213 , T1190 , T1486 , T1078 ).
1.
Canvas Admin and API Authentication Logs — Per NIST AU-2 (Event Logging) and AU-3 (Content Of Audit Records), confirm your logging configuration captures event type, timestamp, source identity, and outcome for all Canvas authentication events.
Alert on: successful logins without MFA (maps to CIS 6.3, CIS 6.5); logins from IP ranges not on your known integration allowlist; service account logins outside business hours; and multiple failed login attempts followed by success (maps to NIST AC-7). Apply D3-LAM (Local Account Monitoring) to detect unauthorized or anomalous Canvas local account activity.
2. Canvas Data 2 Pipeline Logs — Per NIST AU-6 (Audit Record Review, Analysis, And Reporting), review Canvas Data 2 pipeline logs for: unexpected bulk data export jobs; schema access outside normal scheduled windows; API calls from unrecognized client IDs or IPs. Apply NIST AC-23 (Data Mining Protection) principles to identify abnormal data access volume patterns. Use D3-PBWSAM (Proxy-based Web Server Access Mediation) to enforce and log all API calls transiting through intermediary proxies.
3. Identity Provider (IdP) Logs for Canvas SSO — Review IdP logs for Canvas SSO for token issuance spikes, session anomalies tied to Canvas service accounts, and anomalous concurrent session counts (maps to NIST AC-10 — Concurrent Session Control). Per NIST AU-16 (Cross-Organizational Audit Logging), coordinate log collection with your IdP if it is managed by a separate organizational unit or third party.
4. SIEM Alerting — Per CIS 8.2 (Collect Audit Logs), confirm audit log collection from Canvas is active in your SIEM. Create alerts for: Canvas API calls from IPs not on your known integration list; bulk record access from Canvas Data 2 outside scheduled export windows; admin account logins not associated with a known MFA-enrolled identity. Per NIST AU-5 (Response To Audit Logging Process Failures), configure alerts for any gap or failure in Canvas log delivery to your SIEM.
5. Audit Log Integrity and Retention — Per NIST AU-9 (Protection Of Audit Information), ensure Canvas audit logs collected during and after the incident window are write-protected and stored separately from systems that may have been in scope. Per NIST AU-11 (Audit Record Retention), retain all incident-period logs consistent with your defined retention policy to support post-incident forensic analysis. Per NIST AU-4 (Audit Storage Capacity), verify your log storage capacity is sufficient to handle elevated log volume during incident response.
6. Credential and Token Monitoring — Apply D3-CH (Credential Hardening) and D3-CRO (Credential Rotation) countermeasures by monitoring for reuse of rotated credentials or API keys that were invalidated during containment. Use D3-SFA (System File Analysis) to monitor authentication configuration files on any Canvas-adjacent systems for unauthorized modification, relevant given ShinyHunters' historical credential theft and cloud storage exfiltration tactics.
7. Ongoing Threat Intelligence Monitoring — Per NIST AU-13 (Monitoring For Information Disclosure), monitor open-source intelligence sources including Instructure's official security blog and established infosec publications for IOC releases, updated attribution details, and confirmed attack vector information as the investigation progresses.
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 (5)
Sentinel rule: Phishing email delivery
KQL Query Preview
Read-only — detection query only
EmailEvents
| where Timestamp > ago(7d)
| where ThreatTypes has "Phish" or DetectionMethods has "Phish"
| summarize Attachments = make_set(AttachmentCount), Urls = make_set(UrlCount) by NetworkMessageId, Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, ThreatTypes
| sort by Timestamp desc
Sentinel rule: Supply chain / cross-tenant access
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where HomeTenantId != ResourceTenantId
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, HomeTenantId, ResourceTenantId
| sort by TimeGenerated 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: Ransomware activity
KQL Query Preview
Read-only — detection query only
DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType == "FileRenamed"
| where FileName endswith_any (".encrypted", ".locked", ".crypto", ".crypt", ".enc", ".ransom")
| summarize RenamedFiles = count() by DeviceName, InitiatingProcessFileName, bin(Timestamp, 5m)
| where RenamedFiles > 20
| sort by RenamedFiles desc
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
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
T1566
T1199
T1530
T1657
T1213
T1190
+2
AT-2
CA-7
SC-7
SI-3
SI-4
SI-8
+11
MITRE ATT&CK Mapping
T1566
Phishing
initial-access
T1199
Trusted Relationship
initial-access
T1530
Data from Cloud Storage
collection
T1657
Financial Theft
impact
T1213
Data from Information Repositories
collection
T1190
Exploit Public-Facing Application
initial-access
T1486
Data Encrypted for Impact
impact
T1078
Valid Accounts
defense-evasion
Guidance Disclaimer
