Loblaw Breach Exposure: Lunar’s View of The Incident

Canadian retailer Loblaw (loblaw.ca) recently joined the list of brands reporting a security breach involving customer information. The company confirmed that a criminal group accessed part of its IT environment and pulled basic contact details, including names, email addresses, and phone numbers. Passwords and payment data were not taken, but that still leaves customers exposed to targeted phishing and social‑engineering attempts.

There’s another piece to the story from Lunar’s perspective. In March 2026, when the incident came to light, we saw fresh Loblaw credentials appear in infostealer logs: accounts tied to real users with access to SSO, Microsoft 365, and other identity services people rely on every day.

Executive Snapshot

• Domain involved: loblaw.ca
• Exposure window examined: March 2026
• Exposure profile: ~7 separate credential sets
• Primary malware family: Vidar infostealer
• Impacted service categories: SSO, Microsoft 365, broader enterprise identity

Seven exposed accounts might sound small for a company of Loblaw’s size. In practice, identities that sit on top of SSO and M365 can reach email, internal collaboration, and a long list of SaaS tools, meaning a few compromised users can still pose a real threat.

What Lunar Saw Before the Loblaw Incident

Lunar’s platform picked up a small cluster of credential exposures spread throughout the first half of March. After public reporting on the breach, we went back and ran a correlation analysis on March 17, 2026.

That review surfaced roughly seven distinct loblaw.ca credential sets in the wild during the same month the incident was reported. All of them traced back to Windows endpoints, some corporate, some personal, which points to the device layer as the weak spot rather than a single misconfigured server or app.

Infostealers and “Log In, Not Break In”

The malware behind these exposures was Vidar, a well‑known infostealer built to strip data from browsers rather than crash systems. Once it lands on a Windows machine, for example through a phishing link, a convincing installer, or a “free” download, it quietly pulls:

• Saved usernames and passwords
• Session cookies and tokens
• Autofill data and general system details

Those bundles are turned into logs that circulate in criminal markets and closed channels. For attackers and initial‑access brokers, this is ideal fuel for what MITRE ATT&CK calls Valid Accounts (T1078): using real credentials instead of hunting for a software bug.

When the stolen logins belong to SSO or M365, the attacker’s job gets much easier. A single working account can unlock:

• Corporate email and calendars
• Internal chat and shared documents
• Connected SaaS tools tied to the same identity backbone

At first glance, that activity can look exactly like a normal employee session.

What a Vidar‑Fueled Attack Might Look Like

Lunar is not saying any of the ~7 loblaw.ca accounts were used in this specific incident. What we can say is that the pattern around Loblaw looks a lot like attack flows we’ve seen many times:

• A device gets infected: Someone using a corporate laptop or personal computer to access Loblaw resources opens a malicious attachment, installer, or website. Vidar installs silently and starts collecting data.
• Credentials are scraped: The malware steals saved logins and cookies for SSO, M365, and other loblaw.ca‑related services, then sends that bundle back to its operators.
• Logs are monetized: Those credentials are packaged into logs and sold on dark‑web markets or offered in private Telegram channels. Access brokers flag Loblaw entries so buyers can spot them quickly.
• Valid accounts are put to work: A buyer signs in to corporate services with those credentials, or replays the cookies. Without strong, hardware‑backed MFA and tight device‑posture checks, that login can slide through as if it came from a trusted user.

Where People and Devices Come In

The Loblaw data also points to the role of devices. The exposures we saw in March were linked to both corporate Windows endpoints and personal machines used for work tasks. This matches typical hybrid-work patterns, including:

• Quick checks of Microsoft 365 from a home desktop
• SSO‑protected tools opened on a shared family laptop
• Browsers remembering corporate passwords on devices IT never enrolled

Those personal endpoints rarely have the same EDR coverage, patching rhythm, or locked‑down configurations as business hardware, yet they still cache company logins and sessions. If one of those machines picks up Vidar, the first compromise happens outside the monitored network, but the impact is felt organization-wide.

What Security Teams Can Take Away

The Loblaw incident, along with the Vidar‑linked exposures we saw that month, shows how identity risk has moved out of the data center and into every device employees use to sign in. A few practical steps help tighten that gap:

• Use hardware‑backed MFA for high‑value accounts.
• For SSO and M365, especially admin and sensitive roles, shift away from SMS and simple push prompts toward FIDO2/WebAuthn‑style security keys. That makes stolen passwords and many stolen cookies much harder to reuse.
• Limit where credentials live.
• Reduce the chance of storing corporate passwords in local browser vaults on unmanaged devices, and use conditional access to pull sensitive access back to trusted endpoints.
• Watch for your credentials in infostealer logs.
• Track loblaw.ca accounts showing up in new logs and treat each one as a signal: reset passwords, revoke sessions, and review recent activity on those accounts.

You can’t stop infostealers from trying to harvest credentials across the internet. You can narrow the window between when those credentials leak and when they’re made safe again.

Disclaimer

This report is based on telemetry observed by Lunar and publicly available information. The findings presented are provided for informational purposes only. Lunar does not claim direct attribution, nor does it assert that the observed credential exposures were the definitive cause of the reported security incident. This analysis represents a correlation of temporal data points and does not constitute a “smoking gun” or identify “patient zero.”