Canvas LMS Down: Analyzing the Nationwide EdTech Extortion Attack
The situation unfolding with Canvas LMS is a nightmare scenario for EduSec. Seeing that ransom note plastered on the login page for thousands of institutions is bad enough, but the claim of exfiltrating 275 million records is catastrophic.
We need to assume this isn't just a simple index.html swap. If the attacker had access to deface the login page, they likely had write access to the underlying web directory or compromised a CDN asset.
For those of you running Canvas on-prem or with custom integrations, I recommend immediately auditing your web server access logs for suspicious PUT or POST requests or unusual user agents around the time of the breach.
Here is a Splunk query to check for web shell activity or file modifications on the login endpoints:
splunk index=web sourcetype=access_combined uri_path="/login" method IN (PUT, POST) | stats count by src_ip, user_agent, uri_path
| where count < 5
| sort - _time
Also, verify the integrity of your SSO certificates. If they defaced the login, did they also inject a script to harvest credentials before displaying the ransom note?
How is everyone handling the student/faculty communication right now? Are you taking the instance completely offline or trying to run in maintenance mode?
We're treating this as a full Oauth/SAML compromise. Even if the defacement was superficial, the psychological impact on faculty is huge. We forced a password reset for all accounts immediately and are checking our IdP logs for anomalies. If you haven't already, I suggest checking your audit.log for any unusual admin session creations.
grep "admin_login" /var/log/canvas/audit.log | awk '{print $1, $2, $7}' | sort | uniq -c
Stay safe out there, this is going to be a long weekend for sysadmins.
From a SOC perspective, we're seeing a lot of panic-induced traffic spikes. Be careful with the phishing follow-ups. Expect students to receive emails claiming their 'data was leaked' with links to fake credential harvesters. We've already blocked several domains spoofing the official Canvas support domain.
I recommend adding a generic banner to your internal portal warning users not to click on ' breach update' links in their emails.
If we're looking at compromised CDN assets, auditing S3 bucket policies is critical. An attacker with write permissions could replace static files without touching the app server. I'd run this immediately to verify public access settings:
aws s3api get-bucket-policy --bucket your-canvas-assets
Has anyone correlated the defacement timestamp with CloudFront or Fastly log anomalies yet?
While checking S3 is vital, on-prem admins need to hunt for persistence. If they had write access to swap the login page, they likely dropped a webshell. I recommend scanning for recently modified Ruby files in the Rails public directory.
Run this to catch files modified in the last 24 hours:
find /var/www/canvas/public -type f -mtime -1 -ls
Also, check your database roles for any new users created around the breach time to rule out SQL injection.
Verify the exfiltration claims before assuming the worst. If 275 million records actually left, there must be a significant egress trail. Audit your proxy logs for high-volume outbound connections to non-whitelisted IPs during the incident window. You can quickly filter for anomaly-sized data transfers using a query like this:
NetworkEvents
| where SentBytes > 5000000
| summarize TotalSent=sum(SentBytes) by DestinationIP, SourceIP
| sort by TotalSent desc
This helps distinguish between a simple defacement and a full data breach.
Don't overlook the Rails logs themselves. If the defacement wasn't via a direct shell, the production.log might reveal the specific controller or parameter tampering used to overwrite the view. I'd search for anomalous parameters around the time of the incident:
grep -A 5 "Started POST\|PUT" /var/log/canvas/production.log | grep -i "parameters"
Also, audit installed Gems for dependency confusion; custom Canvas installs sometimes pull from unvetted sources.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access