On May 1, 2026, Instructure reported a security incident affecting its environment. While the technical root cause remains under investigation, Lunar’s threat intelligence identified a preceding window of credential exposure tied to Instructure’s domain.
The pattern is familiar. A Windows endpoint becomes infected with an infostealer, browser credentials and session data are harvested, and those stolen identities later become available for abuse. In many modern breaches, attackers do not need to break in through a software exploit. They log in with valid credentials.
What Lunar Saw Before the Instructure Incident
After reviewing Lunar telemetry from July 2025 through March 2026, we observed approximately 33 distinct credential sets connected to Instructure-related identities and services.
These exposures appeared across a mix of corporate and personal Windows endpoints. The affected credentials were tied to access paths commonly used in day-to-day business operations, including:
- Third-party portals used in operational workflows.
- Corporate SSO environments.
- External services connected to employee or partner activity.
Following Instructure’s May 1, 2026 breach notification, Lunar performed a retrospective review and confirmed that these exposures formed a sustained precursor window.
Lunar does not claim that these credentials were the cause of the reported incident. But the pattern shows how stolen identity data can create meaningful risk long before a breach becomes public.
Snapshot: Key Exposure Details
- Domain involved: instructure.com
- Observed exposure window: July 2025 to March 2026
- Approximate distinct exposures: ~33 credential sets
- Primary malware families: LummaC2 and Rhadamanthys
- Impacted infrastructure: Windows endpoints, both corporate and personal
- Targeted service categories: Third-party portals and corporate SSO
Thirty-three exposed credential sets may sound limited when compared to the size of a large technology provider. But in identity-based attacks, scale is not always the issue. A single account with the right access can give an attacker a useful starting point.
The Mechanics of Valid Accounts (T1078)
Infostealers such as LummaC2 and Rhadamanthys are built for efficient data theft. They do not need to destroy files or announce their presence. Their goal is to quietly collect useful identity material from infected machines.
That material often includes:
- Browser-stored usernames and passwords.
- Session cookies and tokens.
- Auto-fill data.
- System metadata that helps attackers understand the victim environment.
Within the MITRE ATT&CK framework, this activity often supports Valid Accounts, also known as T1078. Instead of exploiting a vulnerable application, an attacker uses real credentials to authenticate.
That makes detection harder. A login using valid credentials can look normal at first glance. Security teams may only see subtle signs, such as unusual IP addresses, unfamiliar devices, odd login times, or access from unexpected locations.
A Plausible Attack Pattern
Lunar does not assert that the observed Instructure-related exposures were used in the May 1, 2026 incident. However, the telemetry fits a common pattern seen in infostealer-enabled breaches.
- Initial infection: A user executes a malicious payload on a Windows device. This may happen on a corporate machine or on a personal device used for work access.
- Exfiltration: The infostealer collects browser data, saved credentials, session cookies, and other identity artifacts.
- Distribution: The stolen data is packaged into logs and circulated through underground marketplaces, Telegram channels, or other criminal ecosystems.
- Exploitation: Threat actors search these logs for high-value domains, then attempt to access SSO, third-party portals, or administrative interfaces using the stolen credentials.
This is not always a direct path from infection to breach. Often, it is a long-tail process. Credentials are stolen first, stored or sold later, and only then tested against valuable targets.
Aggregated Timeline Insight
Taken together, the Instructure exposure pattern before the May 2026 announcement looks like this:
July to September 2025
- Moderate exposure activity.
- Early indicators connected to LummaC2 activity.
- Credential sets tied to third-party access paths begin appearing.
October 2025 to January 2026
- Stable exposure activity continues.
- Rhadamanthys infections appear across unmanaged or mixed-use Windows devices.
- Credential risk remains present across the identity layer.
February to March 2026
- Exposure activity reaches its observed peak.
- Credentials tied to third-party integrations and SSO-related access are seen in Lunar telemetry.
May 1, 2026
- Instructure publicly reports the security incident.
- Lunar correlates the prior exposure window with the breach timeline.
The steady rhythm of exposure matters. It suggests that the organization’s identity surface was exposed over months, not only at a single moment in time.
The Human Aspect: Personal Devices and Shadow IT
One important signal in the data is the mix of corporate and personal Windows devices. This reflects a common problem for security teams. Employees, contractors, and partners often access business services from devices outside full corporate control.
Common risk scenarios include:
- Logging into SSO from a personal Windows machine.
- Accessing vendor or partner portals from an unmanaged device.
- Using the same browser profile for work tools and personal activity.
- Saving passwords and sessions in browsers that are not monitored by corporate security tools.
When an infostealer infects one of these devices, it does not need to compromise the corporate network directly. The browser becomes the attack surface. If the browser stores credentials or active sessions, those assets can be stolen and reused.
This is why Shadow IT and unmanaged endpoints remain a major identity risk. The security boundary is no longer only the office network. It extends to every device that touches business applications.
Conclusion: Lessons in Resilience
The Instructure incident is another reminder that credential exposure is not a minor hygiene issue. It is an early warning signal.
Security teams should treat infostealer findings as actionable incidents, especially when they involve SSO, third-party portals, or accounts connected to sensitive workflows.
Device Posture Checking
Restrict access to high-value applications based on device health. Where possible, require managed and compliant devices for SSO, administrative tools, and third-party portals.
Session Management
Shorten session lifetimes for sensitive systems. Revoke active sessions when exposed credentials are discovered. This limits the usefulness of stolen cookies and tokens.
Dark Web and Stealer-Log Monitoring
Monitor for domain-specific credentials in infostealer logs. When exposures are found, reset passwords, revoke tokens, and review recent account activity.
MFA Hardening
Use phishing-resistant MFA, such as FIDO2 or WebAuthn, for privileged users and high-risk applications. Combine MFA with risk-based access controls that flag suspicious login behavior.
Third-Party Access Review
Review external portals and integrations that employees use. These services often sit outside core security monitoring but can still provide attackers with valuable access.
Identity is now one of the most important parts of the attack surface. Infostealers make that surface easier to exploit by turning everyday browser activity into usable access material.
By monitoring the pre-attack phase, security teams can act before stolen credentials become active intrusions.
Previous post